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CROSS-REFRENCE TO RELATED APPLICATIONS 

The present application claims priority of PCT Application Entitled A 
CRYPTOGRAPHIC SYSTEM AND METHOD FOR ELECTRONIC TRANSACTIONS, 
International Application No. PCT/US99/09938, filed May 5, 1999, which claims priority 
of U.S. Provisional Application No. 60/084,257 filed on May 5, 1998. 

FIELD OF THE INVENTION 

The present invention relates generally to a cryptographic system and method for 
secure electronic transactions, and more particularly to an electronic card, which takes the 
form of a "smart card" and/or its equivalent software. 

BACKGROUND OF THE INVENTION 

The generic term, "smart card," generally denotes an integrated circuit (IC) card, 
that is, a credit-card-size piece of plastic with an embedded microchip. The IC chip on a 
smart card generally, but not necessarily, consists of a microprocessor (the CPU), read- 
only memory (ROM), random access memory (RAM), an input/output unit, and some 
persistent memory such as electrically erasable programmable read-only memory 
(EEPROM). The chip can perform arithmetic computations, logic processing, data 
management, and data communication. 

Smart cards are mainly of two types: contact and contact-less. The International 
Standard Organization (ISO) has established specifications for such electronic cards under 
the ISO series. In particular, ISO 7816 applies to integrated circuit(s) cards. Because of 
its computing capability, a smart card can support a multitude of security features such as 
authentication, secured read/write, symmetric key and asymmetric key 
encryption/decryption. These smart card security features make it well suited for 
electronic commerce where data security and authenticity are of primary importance. 
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Smart card use has found application in many specialized fields such as mass 
transportation, health insurance, parking, campus, gas, etc. And its potential use in 
electronic commerce and other financial areas are gaining popularity at a rapid pace. U.S. 
Pat. No. 5,521,362, issued to Robert S. Power on May 28,1996, entitled "Electronic purse 
card having multiple storage memories to prevent fraudulent usage and method 
therefore,"describes an electronic purse application. Power's invention demonstrates a 
smart card's capability to be used as a secure financial instrument and not just as a storage 
device. 

As advances in technology push smart-card chip computing to higher speeds and 
larger memory capacity, the concept of a "multi-application" smart card is increasingly 
becoming economically and physically feasible. U.S. Pat. No. 5,530,232 issued to 
Douglas C. Taylor on June 25, 1996, entitled "Multi-application data card," describes a 
multi-application card, which is capable of substituting for a plurality of existing single- 
application cards and satisfying both financial and non-financial requirements. The multi- 
application card uses a conventional data link to connect between the smart card and the 
remote service provider. Taylor's invention, the multi-application card, does not relate to 
any kind of open network or cryptographic method. 

U.S. Pat. No. 5,544,246 issued to Mandelhaum et al. on" on Aug. 5, 1996, entitled 
"Smart card adapted for a plurality of service providers and for remote installation of same," 
describes a smart card, which allows different service providers to coexist on the same smart 
card. Each service provider is considered a user of the smart card and is installed on the card 
by the issuer/owner of the smart card. Each user is allowed to build a tree-like file structure 
and protect it with a password file. Mandelbaum's invention depicts a smart card allows for 
the creation and deletion of multiple applications. Mandelbaum's smart card controls the 
access to each application by using an appropriate password file. 

U.S. Pat. No. 5,671,279 issued to Taher Elgamal on September 23, 1997, entitled 
"Electronic commerce using a secure courier system," describes a system for implementing 
electronic commerce over a public network using public/private key cryptography. The 
Elgamal patent did not mention the use of a smart card as a tool in conducting the electronic 
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commerce and the participants were authenticated through the use of digital certificates. The 
secure courier system requires a secured channel such as a Secure Socket Layer (SSL) 
between the trading parties over an open network such as the Internet. 

U.S. Pat. No. 5,790,677, issued to Fox et al. on August 4, 1998, entitled "System and 
method for secure electronic commerce transactions," describes a system and method having 
a registration process followed by a transaction process. During the registration phase, each 
participant of a transaction registers with a trusted credential-binding server by sending to the 
server a registration packet. The server produces unique credentials based upon the request 
received and sends them to the request originator. During the transaction phase, the 
originator of the transaction requests, receives and verifies the credentials of all intended 
recipients of the commerce document and/or instrument and encrypts the document and/or 
instrument using the public key of the individual recipient. Thus, each receiving party can 
decrypt and access the information intended only for him. Fox's patent describes a process 
which reflects the theme of the so called "Secure Electronic Transaction" (SET) standard 
which is an ongoing effort supported by several major financial and software companies to 
establish a digital certificate and certificate authority based electronic commerce system. 

U.S. Pat. No. 5,796,840 issued to Derek L. Davis on August 18, 1998, entitled 
"Apparatus and method for providing secured communication," describes a semiconductor 
device, which is capable of generating device-specific key pairs to be used in subsequent 
message authentication and data communication. The semiconductor device uses 
public/private key cryptography to ensure the authenticity of two communicating parties. 

U.S. Pat. No. 5,534,857 issued to Simon G. Laing and Matthew P. Bowcock on July 9, 
1996, entitled "Method and System for Secure, Decentralized Personalization of Smart 
Cards," describes a method and apparatus for securely writing confidential data from an issuer 
to a customer smart card at a remote location. A mutual session key for enciphering data 
transfer between a secure terminal and a secure computer is generated by using a common 
key stored in the secure computer and a retailer smart card. 

It is clear from the inventions mentioned above that the architecture of a secure 
electronic commerce system involves a public key infrastructure and digital certificate 
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authority associated with it. 

On an open network, a secret key-based system is less flexible in terms of key 
distribution and key management, and is more subject to malicious attack. On the other hand, 
a public/private key-based system, with all its advantages over the secret key system, has its 
own daunting task of authenticating transaction parties to one another. The current invention 
presents another system and method, which replaces the need for certificate authorities and 
digital certificates. The current invention is a hybrid system for electronic transactions. The 
hybrid system uses public/private keys during the key exchange phase and uses a session key 
as a secret key during the transaction phase. 

SUMMARY OF THE INVENTION 

In one aspect of the present invention, the system for electronic transactions 
comprises: an electronic card having a cryptographic service for encryption and decryption, a 
data area for storing cardholder information, and a data area for storing service provider 
information; a service provider member terminal responsive to activation of the electronic 
card; and a service provider terminal in communication with the service provider member 
terminal, the service provider terminal decrypting communication from the service provider 
member terminal and encrypting communication to the service provider member terminal, the 
service provider member terminal encrypting communication to the service provider terminal 
and decrypting communication from the service provider terminal. 

In another aspect of the invention, the method of conducting an electronic transaction 
using an electronic card comprises formatting a key exchange request message at a member, 
sending the key exchange request message from the member to a service provider, generating 
a session key at the service provider, formatting a key exchange response message including 
the session key at the service provider, sending the key exchange response message from the 
service provider to the member and using the session key to conduct a transaction. 

In yet another aspect of the invention, the method of conducting an electronic 
transaction using an electronic card comprises formatting a key exchange request message at 
a member, the key exchange request message has a member challenge for the service 
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provider, sending the key exchange request message from the member to a service provider, 
generating a session key at the service provider, formatting a key exchange response message 
including the session key at the service provider, the key exchange response message has a 
response for the member challenge and a service provider challenge for the member and sending 
it to the member, formatting by the member a response for the service provider challenge and 
sending it to the service provider and using the session key to conduct a transaction. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a block diagram showing the relationship among the components of a 
system according to an embodiment of the invention. 

Figure 2 shows the flow of the two transaction phases via a network. 

Figure 3 is the diagrammatic representation of an EC. 

Figure 4 shows the format of the service provider data area. Each service provider's 
information is allocated an entry in the table and is protected by access conditions. 

Figure 5 shows how the digital signatures are used in an embodiment of the invention. 

Figures 6A through 6Q shows the schematic flow chart of the cryptographic system 
and method used in an embodiment of the invention in order to conduct electronic 
transactions via an open telecommunication network, such as the Internet. 

Figure 7 through Figure 1 1 depicts the final format and content of the combined 
request and response messages in the key exchange phase and the transaction phase. 

Figure 12 shows a service provider conducting a transaction with participants that have 
been arranged in series. 

Figure 13 shows a service provider transaction on a network with participants that 
have been arranged in a hierarchical organization scheme. 

DETAILED DESCRIPTION 

A preferred embodiment of the invention is a cryptographic system and method for 

electronic transactions by using an electronic card (EC) in the form of a smart card or 

equivalent software and communicating over a communications network. 

The preferred embodiment of the invention uses an open network, such as the Internet. 
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Alternative embodiments of the invention may use other types of networks. An embodiment 
of the invention may either use a physical smart card, or alternatively, a smart card, which is 
implemented as computer software package and runs on a computing device such as a 
personal computer (PC). Likewise, a merchant involved in a transaction may use a merchant 
device, which is a point-of-sale terminal, or a device, which uses software on a host computer 
to communicate with an EC and a service provider. When a smart card is used, a smart card 
reader is also needed to allow the card to communicate with a host device, such as a network 
ready merchant terminal, a PC, or any other electronic device, which is capable of supporting 
smart card transactions. 

In a public key and digital certificate based system, transaction participants exchange 
public information through the use of digital certificates or other electronic credentials which 
are issued and certified by a certificate authority (CA) or credential binding server. The 
communication between the CA or the server and each participant of the transaction must be 
secure. Random numbers and digital signatures are used to ensure the authenticity and 
validity of the messages transmitted among the participants. 

The cryptographic system and method of the preferred embodiment of the invention 
also uses public/private key cryptography, but it works in a slightly different way. The 
cryptographic system and method does not seek to create another kind of trust relationship as 
the one that exists between holders of digital certificates and the certificate authorities. It 
particularly targets large membership-based financial institutions such as a large credit card 
company and all its cardholders, or a major bank and all its ATM cardholders as its potential 
users. Non-financial institution can also use this cryptographic system and method to conduct 
commercial or non-financial transactions over a network. 

A service provider (SP) provides some service to its members. Financial institutions 
are just one kind of service provider. A service provider can also be non-financial in nature. 
Regardless whether a service provider is a financial institution or a non-financial institution, 
essentially the same process occurs. The only difference between a transaction involving a 
financial institution and a transaction involving a non-financial institution is that the 
messages may include different data fields. 
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When an EC holder signs up with one of the service providers, the service provider 
creates a dedicated entry on the EC. Each entry contains the account information for the 
service provider, the SP's public key, access control information, and other related data. Each 
EC can support a predetermined number (e.g. ten) of such entries and each such entry is a 
representation of one service provider. 

By using the public/private key cryptography, the key distribution process is much 
simplified. The EC holder him/her/self or any trusted third party such as a bank branch or 
even a post office can perform the task. The SP's public key is only used for the initial key 
exchange between the SP and the cardholder. After the initial key exchange step, the SP 
assigns a session key, which protects any further message exchange between the cardholder 
and the SP or between the cardholders' themselves. 

This hybrid system, which uses both public key/private key cryptography and secret 
key cryptography (i.e., session key), is in contrast to other secret-key systems in that in the 
hybrid system, the secret key (i.e., session key) is valid for a single session and is not 
applicable to other sessions. A session has a determinate length of time. A session may 
terminate based upon a time period or upon conditions being satisfied. 

Where a merchant is involved in a transaction, the merchant goes through essentially 
the same procedures as the EC holder to communicate with the SP. The merchant will first 
perform a key exchange with the SP and receive a session key. The session key will be used 
by the merchant for subsequent communication with the SP. The cardholder and the 
merchant digitally sign each message going to the SP and the SP similarly signs the response 
message going back to the cardholder and the merchant. 

In the event that a transaction requires interactions with another certificate-based 
system, the SP, after authenticating the cardholder and the merchant based on further 
information exchange after the initial key exchange, can act as a surrogate-certificate for the 
cardholder and the merchant. In the most extreme case, the SP performs solely this surrogate 
function and becomes a gateway for the certificate-based system. This type of hierarchy is 
highly desirable since it reduces the number of trust relationships needed to carry out a 
transaction among multiple systems. In addition, it eliminates the users' need to carry 
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certificates. 

The preferred embodiment of the invention is a cryptographic system and method for 
electronic transactions by using an electronic card (EC) in the form of a smart card or 
equivalent software and communicating over a communications network. 

In the preferred embodiment of the invention, the network is an open network such as 
the Internet. In alternative embodiments of the invention, other open networks and/or closed 
networks may be used to establish communication between a service provider and its 
members. For example, a service provider may use its own proprietary financial network to 
communicate with its members. 

Any Internet protocol may be used for Internet connections. Example protocols, which 
can be used include TCP/IP, UDP, HTTP, and the like. 

Communication may also be via a communications network transport service such as 
the Public Switched Telephone Network (PSTN) using traditional analog telephone service 
(a.k.a. Plain Old Telephone Service or POTS), or by using a digital communication service 
such as a T-l, El or DS-3 data circuit, Integrated Services Digital Network (ISDN), Digital 
SubscriberLine (DSL) services, or even using a wireless service, and the like. When 
implemented using such a service the invention may be implemented independent of a 
communications protocol (i.e. at an electrical interface layer). 

Communication may also be via a local area network (LAN) or Wide Area Network 
(WAN) such as Ethernet, Token Ring, FDDI, ATM or the like. Example protocols, which 
can be used include TCP/IP, IPX, OSI, and the like. 

Other communication links might include an optical connection, a wireless RF modem 
connection, a cellular modem connection, a satellite connection, etc. 

The invention may be employed as long as a communication path can be established 
between a service provider and its members. The examples above are intended to illustrate 
several examples of the various communications environments in which the invention may be 
practiced. As is clear to one ordinarily skilled in the art, the invention is not limited to those 
environments detailed above. 

The EC can take the form of a smart card device or a software package running on a 
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computer system such as a personal computer (PC). When the EC is implemented on a smart 
card, it can be used on a network-ready computer system such as a PC to transact with 
another member and/or a selected service provider. It will need a read/write interface device 
to communicate with a computer system and some application software such as an Internet 
browser to interface with the cardholder and the network. If the EC is a software package 
loaded into a computer system, then no read/write interface is needed. The exemplary 
embodiment of the invention is for the EC to act as an electronic wallet (or cyber wallet) 
which functions similar to real wallet. A real wallet can carry credit cards, debit cards, ATM 
cards, health provider cards, membership cards, cash, etc. An EC has the digital equivalent of 
all the above-mentioned financial and non-financial instruments and enables conducting 
secure transactions over the Internet. 

A service provider member can be a merchant and/or an EC cardholder. A merchant is 
a member who is paid by the service provider as a result of a transaction. A member can be 
both a merchant and an EC cardholder. A merchant may engage in a transaction with other 
cardholders, which results in the merchant being paid by the service provider. A merchant 
may also be an EC cardholder and purchase supplies, for example, from a merchant supplier. 

The cryptographic system may involve communication between a service provider and 
any number of service provider members. Thus, communication can be between an EC and 
an SP, between a merchant and an SP, between a first EC, a second EC, and an SP, between a 
first merchant, a second merchant, and an SP, etc. An EC may communicate directly with a 
service provider to inquire about an account balance for example. A merchant may 
communicate with a service provider only on his own behalf and not on behalf of an EC 
because, for example, the merchant wants to know his own account balance with the service 
provider. Communication between the SP and its members may follow any permutation of 
the SP and its members. The organization of the communication links between the SP and its 
members may be serial and/or hierarchical. Communication between the SP and its members 
may also be serial and/or via routers, which route the messages between the SP and its 
members. 

The cryptographic method is a two-phased key-exchange-transaction model. The first 
184297-4 9 



34581/C718 



phase is a key exchange phase. The second phase is the transaction phase. In the key 
exchange phase, the members exchange keys with the service provider. The members send 
their keys to the service provider and the service provider uses the keys to send a session key 
to the members. The session key protects any further message exchange between the 
cardholder and the SP or between the cardholders' themselves. In the transaction phase, 
either the SP can direct the transaction or the cardholders themselves may conduct the 
transaction. 

Figure 1 is a block diagram showing the relationship among the components of a 
system according to an exemplary embodiment of the invention involving a cardholder, a 
merchant, and service provider. 

An EC cardholder 20 can conduct a transaction over a network 50 and communicate 
with a merchant either by using an EC read/write device 82 attached to an originating 
computer 84 or by using EC equivalent software 92 running on an originating computer unit 
90. 

A merchant can conduct a transaction over a network by either using a network-ready 
point-of-sale(s) (POS) terminal 40 or by using EC equivalent software running on a merchant 
device 70 to conduct an electronic transaction with a selected service provider 60 via a 
network 50 such as the Internet. 

Once the access conditions to the card have been satisfied, the cardholder can perform 
financial or non-financial transactions with other participants of the system through the 
network 50. In Figure 1, there are three different scenarios in which a transaction over a 
network can be conducted. 

(1) In a POS transaction (Upper left side of figure 1), the cardholder 20 swipes/inserts an 
EC through/into a merchant's EC reader/writer 30 at a merchant's premises. The EC 
reader/writer is connected to a network-ready merchant POS terminal 40. The 
network-ready merchant POS terminal 40 is a secure tamper-resistant programmable 
device comprising an input means such as a keyboard, a display device, a processing 
unit, and an EC read/write device 30 (an EC interface device). It is typically a small 
computer unit such as a PC equipped with a communication link to an open network. 
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The POS terminal communicates to the SP via the network 50. 

(2) (Right side of figure 1) A cardholder can conduct a transaction with other 
participants of the system by inserting the EC 20 into a read/write device 82, which 
is connected to the cardholder's personal computer 84 which is the originating 
computer. The originating computer connects to a network 50 allowing the EC to 
communicate with the merchant computer unit 70. The merchant computer unit 70 
has EC equivalent software 72 that enables the merchant to receive the EC generated 
message and generates a message combining EC information and merchant 
information. Then, the combined message is sent to the SP over a network. 

(3) (Bottom side of figure 1) A cardholder can conduct a transaction with other 
participants of the system by using EC equivalent software 92 on the customer 
cardholder's personal computer 90. The transaction begins at the originating 
computer unit 90, that is, the cardholder's personal computer. The cardholder 
conducts the transaction over a network 50 and communicates with the merchant's 
computer unit 70, which in turn communicates with the SP 60 over a network 50. 

While in the preferred embodiment of the invention, a personal computer is used to hold 
the EC equivalent software, in alternative embodiments of the invention other electronic 
devices can be used to hold the EC equivalent software. 

In the preferred embodiment of the invention, the network used to enable the EC to 
communicate with the merchant is the same network used to enable the merchant to 
communicate with the SP. In another embodiment, the network used to enable the EC to 
communicate with the merchant may not be the same network used to enable the merchant to 
communicate with the SP. In yet another embodiment, the network used to enable one 
merchant to communicate with the SP may not be the same as the network used to enable 
another merchant to communicate with the SP. In still yet another embodiment, the network 
used to enable an EC to communicate to the merchant may not be the same as the network 
used to enable another EC to communicate with another merchant. An embodiment may 
consist of a multiplicity of networks whereby different parties communicate. 

In the preferred embodiment of the invention, a transaction is broken down into two 
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phases: a key exchange phase and a transaction phase. Figure 2 is a specific case, which 
illustrates the two-phase key-exchange-transaction model where the SP directs the transaction 
phase. There is no direct exchange of sensitive information between participants when the SP 
directs the transaction. 

The key exchange phase is the same where the transaction phase is among the 
cardholders themselves and where the SP directs the transaction phase. Where the transaction 
phase is among the cardholders themselves, the cardholders use the SP session key to 
communicate with each other and conduct a transaction. 

Figure 2 demonstrates a financial transaction where the SP directs the transaction phase. 
The transaction shown involves three parties: an EC (a transaction originator) 102, a 
merchant 104, and a service provider (SP) 106. The originating party is an EC cardholder 
who is the consumer and is represented by the computer unit 102. The computer unit 104 
represents the merchant. The computer unit 106 represents the service provider. An SP is 
selected by both an EC and merchant. 

Figure 2 demonstrates a financial transaction wherein the process flow is from an EC to 
a merchant to an SP. The cryptographic method's process flow is not limited to any particular 
order between merchants and EC cardholders. Figure 2 is merely an example of a particular 
transaction, which flows from EC to merchant to service provider. The process flow can also 
go from merchant to EC to service provider. Figure 2 demonstrates how service provider 
members (in this case, the EC cardholder and the merchant) create, append, and send 
messages to a service provider. 

The ten arrows numbered 1 to 10 in figure 2 show how the messages flow among the 
three parties during the two transactions phases. Steps 1 through 4 belong to the key exchange 
phase and steps 5 through 10 belong to the transaction phase. In figure 2, the merchant serves 
as an intermediary between the EC and SP. In step 1, the key exchange request is formatted 
by the EC and sent to merchant. In step 2, the merchant combines his own key exchange 
message with the EC's key exchange message and sends the combination key exchange 
message to an SP. In step 3, the SP formats a key exchange response for the merchant, 
formats a key exchange response for the EC, combines the key exchange responses to form a 
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combined key exchange response and sends the combined key exchange response to the 
merchant. In step 4, the merchant separates the key exchange response for the merchant from 
the key exchange response for the EC and forwards the EC's key exchange response message 
back to the EC. Step 4 concludes the main activities in the key exchange phase. 

The transaction phase begins with step 5. In step 5, the EC formats its transaction 
request message and sends it to merchant. In step 6, the merchant combines the received 
transaction request message with his own transaction request message and sends the 
combination transaction request message to the SP. In step 7, the SP formats a transaction 
response message for the merchant, formats a transaction response message for the EC, 
combines the transaction response messages and sends the combined transaction response 
message back to merchant. In step 8, the merchant separates the transaction response 
message for the merchant from the transaction response message for the EC and forwards the 
EC's transaction response message back to the EC. In step 9, the EC formats a confirmation 
message and sends it to the merchant. In step 10, the merchant combines the received 
confirmation message with his own confirmation message and sends the combination 
confirmation message the SP. Step 10 concludes the transaction phase of a transaction. 

While figure 2 demonstrates a simple transaction, some transactions may involve 
multiple messages. During some transactions, more than one message may be required to 
complete each phase, in which case, those messages will follow the same rules of 
combination and flow pattern. For example, during the transaction phase, the SP may require 
that the EC and the merchant send over account information first. If the account information 
is verified to be valid, the SP sends confirmation of the account information in the response 
message. Once the merchant and the EC receives the response message, then the EC and the 
merchant send the transaction amount and other transaction related information in the next 
message going to the SP. The SP subsequently approves or disapproves the transaction. The 
steps in figure 2 apply to both the account message and the transaction message. 

If the completion of a transaction requires interaction with some external system such as 
a public key and digital certificate based system 108, the SP will act as a surrogate-certificate 
for the EC and the merchant and deal with the external system on behalf of the EC and the 
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merchant. A desired result of the invention is to shield all of the participants of a transaction 
from an external system and therefore reduce the number of trust relationships needed to 
complete a transaction. If a participant of a transaction has dual membership of this system 
and an external system, then he has a choice of either acting as a member of this system or as 
a member of an external system. In the latter case, the SP will interface with the participants 
using the rules of an external system. For example, to deal with an external public and digital 
certificate or credential based system, the SP has in its possession all of the required 
certificate(s) or credential(s) which satisfies the trust relationship demanded by the external 
system. Such credentials are required in order for the SP and the external system to complete 
the transaction initiated by the EC and the merchant. In this case, only the SP needs to have a 
trust relationship with the external system. Based on this trust relationship, individual ECs 
and merchants are able to complete transactions with the hypothetical external system. 

Figure 3 is a diagrammatic representation of a preferred embodiment of an EC. In a 
preferred embodiment of the invention, an EC is internally composed of the 
software/hardware components shown in Figure 3. The EC is ISO 7816-based and supports 
the same kind of communication protocols and commands as defined in ISO 7816. 

The EC has a card operating system 550 to manage the EC's internal resources. The on- 
card cryptographic service 650 can be implemented in software or be provided by a 
cryptographic co-processor (not shown in figure 3), or other hardware solutions, or a hybrid 
of software and hardware. 

One of the unique features of the EC is the service provider data area (SPDA) in the EC 
memory, which contains the service providers' account and key information. The service 
provider data area (SPDA) 700 contains a number of slots. In the preferred embodiment, the 
SPDA contains a pre-defined number (e.g. ten) of slots - one for each potential service 
provider. In another embodiment, the number of slots may be dynamically changed. A 
record for each service provider can be placed into an empty slot. Each record contains the 
account number, public key, and other related information for a specific service provider. 

Depending on the EC design, the SPDA can optionally allow each SP to include some 
software (such as an "applet" in the JAVA terminology) to manage its own on-card data and 
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provide an interface between the SP card data and the host application. In other words, the 
SPDA can contain more than just simple data; it can allow each SP to put a self-contained 
application program (such as an applet) on the EC to provide its own unique service to the 
cardholder. The advantage of this type of design is that the EC itself is now detached from 
the type of service it can provide. Each SP can bring with it its own service capability. When 
another SP replaces an on-card SP, there will be no change necessary to the EC platform. 
The new SP applet is simply loaded into the card and it will perform what it is designed to do. 

In the SPDA, each service provider is allocated space for public keys. In many 
transactions, only one key pair is used, but for some online transactions, two or more key 
pairs are required. If the SP uses the same public/private key pair for both the incoming and 
the signing of outgoing messages, then one public key is enough. If the SP uses a different 
key pair for signing, then both SP public keys (one for incoming messages and one for the 
signing of outgoing messages) are required in the SPDA. 

In the preferred embodiment of the invention, two public/private key pairs rather than 
one public/private key pair is used to communicate with other applications through a network 
because using two public/private key pairs rather than one public/private key pair provides 
greater security. One pair is used for decrypting an incoming message, i.e., the sender 
encrypts the message using the recipient's public key and the recipient decrypts the message 
using the corresponding private key. The other pair is for the sender to digitally sign the 
message he sends out and the recipient to verify the digital signature using the corresponding 
sender's public .key. Each service provider is allocated space for the number of public 
keys used by the service provider. If the SP uses the same public/private key pair for both 
incoming messages and signing of outgoing messages, then one public key is enough. If the 
SP uses different key pairs for receiving and signing messages, then both of the SP's public 
keys are required in the SPDA. 

In an alternative embodiment of the invention, more than two public/private key pairs 
may be required and used by a service provider for even greater security. 

When an EC holder is issued a new financial or non-financial instrument, the issuing 
institution or a trusted third party will load the needed information comprising a record into 
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an available slot. The information in the slot can be erased when the service provider account 
is closed. Some of the information in a slot can be read and modified during a transaction, 
e.g. an account balance. Some information such as account number is write protected, but 
can be read. Some information such as a private key is both read and write protected. The 
access conditions 600 contain security information such as PINs, biometric data, etc., that an 
EC user must submit to open the card for use or to gain access to the information stored on 
the card. 

Traditional Personal Identification Numbers (PINs) or other security measures such as 
biometrics data are used to protect the EC. Biometrics involves the measurement of a 
cardholder's biological traits, such as physical traits and behavioral traits. A biometric system 
may measure an individual's fingerprints, hand-geometry, hand writing, facial appearance, 
speech, physical movements, keyboard typing rhythms, eye features, breath, body odor, 
DNA, or any other physical attribute of the cardholder. The functions provided by an EC can 
be activated only after all the access conditions have been satisfied. Each service provider 
residing on the card can optionally implement other access conditions. 

Figure 4 shows the format of the service provider data area of a preferred embodiment of 
the invention. Each service provider's information is allocated an entry in the table, which 
can be protected by additional access conditions. The PIN 712 and the miscellaneous data 
field 714 allows the service provider to provide extra protection or data field to the instrument 
it supports. The name field 702 contains the names of the service providers, which can be 
used by the cardholder at the beginning of an online transaction to initially select the 
applicable service provider for a transaction. The key type field 704 specifies the type of key 
the service provider chooses to use, secret key, public key, etc. The key value 706 and 
account information fields 708 contain information unique to each service provider. The card 
type field 710 specifies the type of instrument a service provider supports. 

In the preferred embodiment of the invention, the on-card Operating System (COS) 
provides some fundamental services for the cardholder. Following is a list of general 
functions which can be performed by the COS: 



184297-4 



34581/C718 



(1) Traditional OS functionality such as Memory management, task management, etc 

(2) External communication-read/write of user data and communication protocol handling. 

(3) Loading and updating of on-card cardholder information. 

(4) User PIN changes. 

(5) Service Provider Data Area management-such as loading and updating of individual 

service provider information, SPDA access control, etc. 

The COS will also provide support during various stages of a transaction. For example, 
the COS can handle the SP selection at the beginning of a transaction and record the 
transaction into a log file when the transaction has been completed. An embodiment of the 
invention may implement one of the following two design approaches to the COS or a hybrid 
of the two design approaches: 

(1) Most of the intelligence can be put into the COS whereby the COS supports most of the 
EC functionalities. Consequently, each on-card service provider area relies on the COS 
to carry out the transaction with the merchant and the SP. In this approach, the COS can 
provide a uniform interface with the outside world for all on-card SPs and efficiently 
carries out the transaction once a SP has been selected. 

(2) Alternatively, the COS can be a pool of general services each on-card SP can utilize. 
Each SP data area can contain applets, which have the intelligence to carry out a 
transaction with the merchant and the SP. In this approach, the SP has more opportunity 
to implement its own unique feature when performing a transaction. 

Figure 5 shows how digital signatures are used in the preferred embodiment of the 
invention. A sender of a message first prepares and sends the data portion of a message M 
900 through a one way hash algorithm, H(*) 902. The output from the hash algorithm is 
called the message digest MD of the data portion of message M 903. The MD is then 
encrypted, E(MD) 904, i.e. digitally signed, using the sender's private key (Pri). The result is 
called the digital signature DS of a data portion of a message M. The DS is then combined 
with the original data portion of the message M 900 and forms a complete message 906 ready 
for transmission to a recipient through a network 50. 
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The public-key encryption/decryption function can be any of a number of 
encryption/decryption functions. RSA ? which takes its name from the first initials of RSA 
developers' last names (Ronald Rivest, Adi Shamir, and Len Adelman), is just one example 
of a public-key encryption/decryption method, which can be used in an embodiment of the 
invention. 

When the intended recipient receives the message from a network 50, he first separates 
the data portion of the message M 900 from the digital signature 912 combined with it. The 
recipient then runs the data portion of the message M 900 through the same hash algorithm 
910 that was used to encode the data portion of message M 900, and consequently obtains a 
message digest MD A 9 1 1 of the data portion of message M. The recipient then decrypts 
D(DS) 908 using the EC's public key, the digital signature 912 contained in the original 
message using the sender's public key and recovers the original message digest, denoted here 
as MD 909. MD 909 is compared with the new calculated MD A 91 1 for correctness. If they 
are not identical, the original message has been corrupted and should be rejected. 

Following is a list of symbols and abbreviations used in the figures 5 through 1 1 : 
Acknowledgement Data EC = A part of the message sent back by the EC to the SP. It notifies 
the SP that the previous message has been successfully received and processed. 
Acknowledgement Data M = A part of the message sent back by the merchant to the SP. It 
notifies the SP that the previous message has been successfully received and processed. 
AI EC = Account information of EC holder. 
AI M = Account information of merchant. 
CRYPTO - Cryptogram 
D = Decryption function 
Dsp-Private-Key = Decryption using SP's private key. 
DS = Digital signature function. 

DSEQ.private.Key = Digital signature signed by the EC on a message. 
DS^pri^Key^ Digital signature signed by the merchant on a message. 
D S S p. Private . Key = Digital signature signed by the SP on a message. 
E = Encryption function. 
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E (Data) = Encryption of data under a data encryption key. 
E SP -pk> Esp.p^Key = Data encrypted by SP public key 

E skey-Ec, D skey-Ec = Encryption/Decryption using the session key that the SP generated for the 
EC. 

E skey-M, D skey-M = Encryption/Decryption using the session key that the SP generated for the 
merchant. 

EC = Electronic card, or electronic card equivalent software 

H (M) = Apply a one-way hashing algorithm on M. It generates the message digest (MD) of 
M. 

KE = Key exchange phase. 

M = Merchant 

MD = Message Digest 

MD A = Message Digest produced by message recipient using the message just received as 
input data. 

MD EC = The message digest of a message going from EC to SP. 

MD M = The message digest of a message going from merchant to SP. 

MD SP . M = The message digest of a message going from SP to merchant. 

MDsp-ec ~ The message digest of a message going from SP to EC which is by passed by 

merchant. 

PLAIN TEXT: Transaction data, which can be transmitted without encryption. Plain text can 
be different for different messages and transaction parties. 

PLAIN TEXT EC = Part of the transaction data provided by EC in its outgoing messages. Plain 
text data fields are not security sensitive. Therefore, they are transmitted without encryption. 
Note that the content of this symbol can be different when used in a different message. 
PLAIN TEXT M = Part of the transaction data provided by merchant in its outgoing messages. 
Plain text data fields are not security sensitive. Therefore, they are transmitted without 
encryption. Note that the content of this symbol can be different when used in a different 
message. 

PLAIN TEXT SP . EC = Part of the transaction data provided by SP for EC only in its outgoing 
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messages. Plain text data fields are not security sensitive. Therefore, they are transmitted 
without encryption. Note that the content of this symbol can be different when used in a 
different message. 

PLAIN TEXT SP . M = Part of the transaction data provided by SP for merchant only in its 
outgoing messages. Plain text data fields are not security sensitive. Therefore, they are 
transmitted without encryption. Note that the content of this symbol can be different when 
used in a different message. 

STD = Sensitive transaction data, which requires encryption during data transmission. 
STD EC = Sensitive transaction digital data provided by EC in its outgoing messages. Note that 
the content of this symbol can be different when used in a different message. 
STD M = Sensitive transaction digital data provided by merchant in its outgoing messages. 
Note that the content of this symbol can be different when used in a different message. 
PK = Public key 

EC-PK, PK EC = Public key of the electronic card. 

M-PK, PK M = Public key of the merchant. 

SP-PK, PK SP = Public key of the selected service provider. 

Response Datagp.^ = A part of the message sent back by the SP to the EC during the 
transaction phase of a transaction. It can include approval/disapproval data and/or any other 
relevant data. 

Response Data SP _ M = A part of the message sent back by the SP to the merchant during the 
transaction phase of a transaction. It can include approval/disapproval data and/or any other 
relevant data. 
RN = Random number. 

RN EC = Random number generated by the EC and is sent to SP. 

RN SP . EC = Random number generated by the SP and is sent to EC. 

RN M = Random number generated by the merchant. 

RN SP _ M = Random number generated by the SP and is sent to M. 

SP = Financial or non-financial service provider 

TA = Transaction (currency) amount. 
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1 Transaction Identification Number SP _ EC? TID SP _ EC (Transaction ID SP _ EC ) = A data field whose 
value is assigned by the SP during the key exchange phase of a transaction. The EC will use 
this value to communicate with the SP during the same transaction. 

5 Transaction Identification Number SP _ M , TID SP _ M (Transaction ID^.m) = A data field whose 
value is assigned by the SP during the key exchange phase of a transaction. The merchant 
will use this value to communicate with the SP during the same transaction. 
* = Combine or concatenation of data within an encryption E or a decryption D. 

1 0 Figures 6 A through 6Q comprise the flowchart for a preferred embodiment of the 

cryptographic system and method. For the purpose of simplifying the description and 
symbolism contained in figures 6A through 6Q, the flowchart assumes that each of the parties 
involved in the transaction uses one key pair. In another embodiment of the invention, two 

15 public key pairs may be used, in which case, both public keys need to be exchanged. 

The preferred embodiment of the invention consists of two distinct phases: the key 
exchange phase and the transaction phase. 

20 PHASE I: KEY EXCHANGE PHASE (HANDSHAKE PHASE) 

The EC cardholder inserts the EC into a card read/write device or starts the EC 
equivalent software and enters a PIN number and/or satisfies the access conditions 1 10 to use 
the EC card. The entered security information conditions is compared 112 with the on-card 

25 information 1 14 to verify that user is authorized to use the EC. If the security information 
• does not match the card security information, then the request to use the card is rejected 116. 
Otherwise, the card is unlocked 1 18 for use. Once the card is unlocked, the user can request 
the list of the on-card SPs available for selection and make a selection 120 by issuing an SP 
selection command to the EC. Once the SP is selected, the EC proceeds to start the key 
exchange (KE) with the SP. The public key of the selected SP, represented by the symbols 
SP-PK and PK SP is obtained from the EC's SPDA and is used to encrypt messages that will 
be sent to the SP. 

^ The main purpose of the KE is to securely send the cardholder's public key, PK EC 126 

and an EC random number, RN EC 124 to the SP. The SP response to the EC is to assign a 
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session key and a transaction ID to the EC, which will be used by the EC to communicate 
with the SP for the rest of the transaction. To format the KE message, the EC generates a 
random number, RN EC 124, concatenates it with the EC's public key, PK EC 126, and EC 
sensitive transaction data STD EC 128 relevant to the transaction and/or required by the SP. 
The EC encrypts them 122 using the SP's public key, PK SP , retrieved from the SPDA 120. 
The resulting EC cryptogram, E ES . PK (RN EC *PK EC *STD EC X is then combined 130 with the 
plain text portion of the message, PLAIN TEXT EC 132, if any, to form an EC combination 

message, PLAIN TEXT EC *E SP . PK (RN EC *PK EC *STD EC ). The EC's public key PK EC 126 may 

be placed in the plain text PLAIN TEXT EC instead of being encrypted when forming the EC 
combination message. 

Only sensitive data is encrypted. Non-sensitive response data is included in the plain 
text. Only the SP is able to read the sensitive data. In a multi-party transaction, the SP has 
full access to the sensitive information of all the participants. 

The resulting EC combination message is then sent through a hashing algorithm 134 to 
form a hash message, which is the EC message digest MD EC . The EC message digest MD EC 
is digitally signed by the EC 136 using the EC private key 138 to form a digitally signed 
message DS EC _ Private _ Key , The digitally signed message DS^.^^.^ is then combined 140 with 
the EC combination message. The combination of the plain text PLAIN TEXT EC cryptogram 
CRYPTO EC and the digital signature DS EC _ Private „ Key is the KE message from the EC and is sent 
to the merchant 158 through a network. Plain text includes all the transaction data fields that 
are not sensitive in nature and therefore can be transmitted in a clear, discernable form; they 
do not need to be encrypted. These data fields are different for each message and are defined 
by the transacting parties. 

To communicate with the SP, the merchant goes through essentially the same steps to 
format its own KE message with the SP as the EC goes through to format the EC's KE 
message with the merchant. The cardholder and the merchant do not communicate with the 
SP individually, but through a combined message. Consequently, there will be no need to 
exchange any confidential financial information between the cardholder and the merchant. 
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1 The merchant prepares his device for the transaction 142 and selects from his own SPDA, 

which resides within the merchant's device, the same SP as the EC cardholder has selected for 
the transaction 144. The public key of the SP, represented by the symbols SP-PK and PK SP is 

5 obtained from the SP's SPDA and is used to encrypt messages that will be sent to the SP. 

To format its own KE message, the merchant generates a random number, RN M 148, 
concatenates it with the merchant's public key, PK M 150, and the merchant's sensitive 
transaction data STD M Sensitive transaction data is data that is relevant to the transaction 

1 0 and/or required by the SP 1 52. The merchant encrypts 146 the combined data using the 

public key of the service provider, PK SP . The resulting cryptogram is then combined 154 with 
the plain text portion PLAIN TEXT M 156 of the message, if any, to form a merchant 
combination message. The merchant's public key PK M 150 may be placed within the plain 

25 text PLAIN TEXT M instead of being encrypted when forming the merchant combination 
message PLAIN TEXT M *E SPLPK (RN M *PK M *STD M ). 

The merchant combination message [PLAIN TEXT M *E SP _ PK (RN M *PK M * STDj^)] is 
further combined 158 with the EC's KE message {[PLAIN TEXT EC *E SP _ 

20 PK(^Ec*PK EC *STD EC )] Ii: DS EC . Private . Key } to form the data portion of the KE message for both 
the merchant and the EC, i.e., the EC-merchant combination message {[PLAIN TEXT EC *E SP _ 
PK (RN EC *PK EC *STO^^^ TEXT M *E SP . PK (RN M *PK M *STD M )]. The EC- 

merchant combination message is sent through a hashing algorithm 160 to form a hash 

25 message, which is the merchant message digest MD M . The merchant message digest MD M is 
digitally signed 162 by the merchant using the merchant's private key 164 to form a merchant 
digitally signed message DS^p^^. The merchant digitally signed message DS^p^^ is 
then combined 166 with the data portion of the message, i.e., the EC-merchant combination 
message to form a key exchange request message « { [PLAIN TEXT^ * E SP , 
PK (RN EC *PK EC *STD EC )] * DS EC . Private . Key } * [PLAIN TEXT M * E SP . PK (RN M *PK M *STD M ) ] » * 
DSM.pri^^y for both the merchant and EC. This final message is sent to the SP through a 
network. Figure 7 represents the final format and content of the key exchange request 

^ message from a merchant to an SP. 

In the preferred embodiment of the invention, the merchant does not check the MD of 
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the EC's request message MD EC because the EC encrypts his public key. However, in an 
alternate embodiment of the invention, if the EC chooses not to encrypt his public key then 
the merchant can optionally check the EC's MD before passing it to the SP. In either the case 
where the EC encrypts his public key or where the EC does not encrypt his public key, for 
enhanced security and to avoid possible processing errors by the merchant, the SP can still 
check the EC's MD. When the merchant receives a combination response from the SP for 
both himself and the EC, the merchant does not have to check the MD for the EC since it is 
part of the overall message formed by a single originator ~ the SP. The merchant only needs 
to check the MD of the overall message he receives from the SP. 

When the SP receives the KE request message, the SP first separates 168 the data 
portion of the KE request message from the DS and feeds the data portion of the KE request 
message into a one-way hash algorithm to recalculate the message digest, which becomes 
MD M . The SP then separates the merchant's plain text PLAIN TEXT M , cryptogram 
CRYPTO M , digital signature DS^p^^ and the EC's KE request message PLAIN 
TEXT EC *CRYPTO EC *DS EC _ Private _ Key . Using its own private key, the SP decrypts merchant's 
cryptogram 170 and recovers, among other information, the merchant's random number RN M 
148 and the merchant's public key PK M 150. The SP then uses the recovered PK M to decrypt 
the digital signature signed by the merchant DS M _ Private _ Key and recovers the MD M for the 
merchant's KE message. The SP compares 172 the newly hashed MD A M 168 with the MD M 
170 recovered by decrypting the DS from the original KE message. If there is a discrepancy 
between MD A M and MD M found, then the KE message has been corrupted and is therefore 
rejected 174. If MD A M and MD M match, then the SP separates the data portion of the EC's KE 
request message from the DS and feeds the data portion of the EC's KE request message into 
a one-way hash algorithm to recalculate the message digest (MD A EC ). The SP then separates 
the EC's plain text PLAIN TEXT EC , if any, cryptogram CRYPTO EC , and digital signature 
DS EC _ PrivateKey , in the data portion of the EC's KE request message 176. Using its own private 
key, the SP decrypts EC's cryptogram and recovers, among other information, EC's random 
number RN EC and EC's public key PK EC . The SP then uses the recovered PK EC to decrypt the 
digital signature signed by EC and recovers the MD EC for EC's KE message. In the step 178, 
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1 SP compares the newly hashed MD A EC 176 with the MD EC recovered by decrypting the DS 
from the original KE message. If there is any discrepancy found, the KE message has been 
corrupted and is therefore rejected 180. Otherwise, SP is ready to send a KE response 

5 message back to merchant and EC. 

To format the KE response message for the EC, the SP generates a random number, 
RN SP _ EC 184, and a session key Skey EC 186 for the EC, combines them with the EC generated 
random number, 188 RN EC , service provider sensitive transaction data STD SP _ EC 190 and 

10 encrypts them 192 using the EC's public key PK EC . The resulting cryptogram, 

E EC .p K (RN EC *RN SP . EC *Skey EC ^STD SP . EC ), is combined 196 with a transaction identification 
number, TID SP _ EC 194 assigned to the EC by the SP and plain text, PLAIN TEXT SP . EC 195, if 
any, to form the data portion of the response message for the EC. The SP runs this data 

1 5 through a hash algorithm to calculate the message digest MD^.^ 198. Using its own private 
key 202, the SP creates a digital signature DS SP _ Private _ Key 200 for the response message by 
digitally signing the message digest MD SP . EC . After combining 204 the data portion of the 
message with the newly calculated DS SP . Private _ Key , the SP's KE response message for the EC is 

20 complete, [TID SP _ EC * PLAIN TEXT SP _ EC *E EC _^^ 

Key- 
To format the KE response message for the merchant, the SP generates a random 
number RN SP . M 208 and a session key Skey M 210 for the merchant and combines them with 

25 the merchant generated random number RN M 212, sensitive transaction data STD SP . EC 214 and 
encrypts them 206 using the merchant's public key PK M recovered in 170. The resulting 
cryptogram is combined 2 1 6 with a transaction identification number, TID SP . M 218, assigned 
to the merchant by the SP and plain text, PLAIN TEXT SP . M 220, if any, to form the data 

30 portion of the response message for merchant. The resulting combination message, TID S p. 
M *PLAIN TEXT SP . M *E M . PK (RN SP . M *RN M *Skey M *STD SP . M ) is further combined 222 with the 
KE response message for the EC, [TID SP . EC *PLAIN TEXT SP . EC *E EC . PK (RN SP . 
EC *RN EC *Skey EC *STD EC )]*DS SP . Private . Key , to form the data portion of the SP's final KE 

35 response message, [TID S p_ EC *PLAIN TEXT SP . EC *E EC . PK *(RN SP . 
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1 E C mc*Skey EC *STD EC )r^ 

M *RN M *Skey M *STD SP _ M )]. The SP runs the data portion through a hash algorithm to 
calculate the message digest 224. Using its own private key 228, the SP creates a digital 

5 signature, DS SP _ Private _ Key 226, for the response message by digitally signing the message digest. 
After combining 230 the data portion of the message with the newly calculated DS 226, the 
KE response message for both the EC and the merchant is complete. The response message 
<<{[TID SP _ EC *PLAINTC^^ 

10 Key) * [TID SP _ M * PLAIN TEXT SP _ M *E M _p K (RN SP _ M *RN M * Skey M * STD SP . M )]»DS SP . Private . Key is sent 
back to the merchant through a network. Figure 8 depicts the final format and content of the 
combined KE response message from the SP to the merchant. 

When the merchant receives the KE response message 232, the merchant first separates 

1 5 the DS SP _ Private _ Key , which was signed by the SP, and then feeds the data portion of the combined 
KE response message into a one-way hash algorithm to recalculate the message digest MD A SP _ 
M . The merchant then separates the data portion of the SP's KE response message, i.e., TID SP . 
m? PLAIN TEXT SP . M , CRYPTO SP . M , [(TID SP . EC ^PLAIN TEXT SP . EC *CRYPTO SP . EC )]*DS SP . 

20 private-Key T& e merchant uses SP's public key (selected from 144) to decrypt the digital 

signature DS SP . Private . Key to recover the message digest MD SP _ M . The merchant compares 234 the 
newly hashed MD a sp _m with the MD SP _ M If there is any discrepancy between MD A SM and 
MD SP _ M , the ICE response message has been corrupted and is therefore rejected 236. If MD A SP . 

25 M and MD SP . M match, then the merchant identifies the part of the response message which is 

meant for him and decrypts the cryptogram CRYPTO SP . M 23 8 using his own private key. The 
merchant should be able to recover the original random number RN M (of 148) that he sent to 
the SP in the KE request message. The merchant compares 240 the recovered random 

30 number RN M (of the step 238) with the original random number RN M . If they are not equal, 
• then the message has been corrupted and the message is rejected 242. Since the random 
number RN M can only be recovered by the SP using the correct SP private key, it is assured 
that the sender of the message is indeed the selected SP. The merchant then forwards the 

35 EC's KE response message [(TID SP . EC * PLAIN TEXT SP _ EC *CRYPTO s ^ the 

EC and prepares for the transaction phase of the transaction. 
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1 When the EC receives the KE response message 260, the EC first separates the DS SP . 

private-Ker which was signed by the SP, and then feeds the data portion of the KE response 
message for the EC into a one-way hash algorithm producing a MD A SP _ EC . The EC then 

5 separates the data portion of the message, i.e., TID SP _ EC , PLAIN TEXT SP _ EC , CRYPTO SP . EC , 
DSgp.private.key. The EC uses SP's public key (selected in 120) to decrypt the digital signature 
DSsp.private.key message and recovers the message digest MD SP _ EC . The EC compares 262 the 
newly hashed MD A SP . EC (in 260) with the MD SP . EC recovered by decrypting the DSgp.private.key 

IQ from the KE response message for EC. If there is any discrepancy between MD A SP , EC and 
MD SP . EC found, the KE response message for the EC has been corrupted and is therefore 
rejected 264. If MD A SP . EC and MD SP _ EC match, the EC identifies the part of the response 
message which is meant for him and decrypts 266 the cryptogram CRYPTO SP . EC which is 

15 contained in the message, using his own private key. The EC should be able to recover the 
original random number RN EC (of 124) that was sent in the EC KE request message. The EC 
compares 268 the recovered random number RN EC (of 266) with the original random number 
RN EC (of 124). If the random numbers are not equal, then the message has been corrupted and 

2o the message is rejected 270. Since only the SP using the correct SP private key can recover 
the random number RN EC , this serves to ensure that the sender of the message is indeed the 
selected SP. The EC prepares for the transaction phase of the transaction. 

There will be a predefined timeout period set in the EC and the merchant. During a 

22 transaction, if a response message is not received within a timeout period, the EC and the 
merchant will consider the transaction aborted and will either retry or start the recovery 
process. 

After successful completion of the KE message exchanges, the SP has EC's public key 
30 and the merchant's public key. At this point, both the EC and the merchant has a random 
number, a transaction ID, and a session key from the SP. The EC and the merchant must 
send the two random numbers recovered from the KE response message back to the SP to 
complete the key exchange phase of the transaction. This can be done in two ways. The 
random numbers can be sent back through a confirmation message from both the EC and the 
merchant. Or the random numbers can be sent back as part of the next message going out 
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1 from the EC and the merchant to the SP, such as a transaction message. The second method is 
simpler and is described in phase II below. The random numbers are used only once to 
ensure the correctness of the key exchange between the SP and merchant, and the SP and EC. 

5 Once the session keys and transaction identification number have been established, the 
random number are no longer be used. 

PHASE II: TRANSACTION PHASE 

jq During the transaction phase, the merchant and the EC each sends their own account 

information such as an account number and other transaction related data such as transaction 
amount, request for approval or other processing, to the SP. Again, the EC and the merchant 
talk to the SP individually but through combined messages and the merchant is responsible 

25 for combining the messages and sending them as one message to the SP. 

The EC first forms the transaction message by concatenating the random number RN SP _ EC 
274 from the SP and the EC's account information with the selected SP, AI EC 276, transaction 
amount TA 280 and any other sensitive data 278 relevant to the transaction and/or required 

2Q by the SP. The EC encrypts 272 them using the session key Skey EC assigned by the SP. The 
Skey EC is a secret key and uses a cryptographic algorithm different from the cryptographic 
algorithm used for the public key encryption. The resulting cryptogram CRYPTO EC , i.e., 
SkeyEcCRNsp.Ec^STDec^AlEc^TA), is then combined 282 with the transaction ID TID SP _ EC 284 

2^ and the plain text PLAIN TEXT EC 286, if any, to form the data portion of the EC's transaction 
message, TID SP _ EC *PLAIN TEXT EC *CRYPTO EC . The data portion 282 is fed into a one-way 
hash algorithm 288 to calculate the message digest MD EC and the MD EC is then digitally 
signed 290 by the EC's private key 292. The resulting digital signature 290 is combined with 
the data portion of the message (from 282) 294 to form EC's transaction request message and 
then sent to the merchant, [TID SP _ EC *PLAIN TEXT EC * Skey EC (RN SP _ 
EC *STD EC :f: AI EC !l: TA)] s!! DS EC _ Private . Key . 

The merchant goes through essentially the same steps to form his transaction message. 

^ The merchant forms his transaction message by concatenating 246 the RN SP . M from the SP 
and the merchant's account information with the selected SP, AI M 248, transaction amount 
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1 TA 252 and any other sensitive data STD M 250 relevant to the transaction and/or required by 
the SP. The merchant encrypts them 244 using the session key Skey M assigned by the SP. 
The session key Skey M is a secret key and is created using a different cryptographic algorithm, 

5 such as DES, from the cryptographic algorithm used for public key encryption. The session 
key Skey M is used to perform the encryption at this point to create the cryptogram CRYPTO M . 
The resulting cryptogram CRYPTO M , i.e., Skey M (RN SP _ M *STD M *AI M *TA), is then combined 
254 with the transaction ID TID SP _ M 256 and the plain text PLAIN TEXT M 258, if any, to form 

IQ the data portion of the merchant's transaction message, TID SP _ M *PLAIN TEXT M *CRYPTO M . 
This data is combined 296 with the EC's transaction request to form the data portion of the 
final transaction request message for the SP, [TID SP _ EC *PLAIN TEXT EC *Skey EC (RN SP _ 

15 m*STD m *AI m *TA)]. As before, the merchant feeds his combined data through a one-way 

hash algorithm 298 to calculate the message digest MD M and the MD M is then digitally signed 
300 by the merchant's private key 302. The resulting digital signature DS^p^^.^ 300 is 
combined 304 with the data portion of the message (from 296) to form the final transaction 

20 request message and is then sent to the SP, {[TID SP _ EC *PLAIN TEXT EC *Skey EC (RN SP _ 
. EC *STD EC *AI EC *TA)]^ TEXT M *Skey M (RN SP _ 

M *STD M *AI M *TA)]}*DS M „ Private . Key . Figure 9 depicts the final format of the transaction request 
message. 

25 When the SP receives the transaction request message, the SP first checks 306 the two 

transaction identification numbers, i.e., TID SP _ EC and TID SP _ M , sent by the EC and the merchant 
and makes sure they are valid. When either TID SP . M (of 218) or TID SP . EC (of 194) is found 
invalid 306, then the message is rejected 308. If the transaction identification numbers are 

30 both valid, then the SP proceeds to separate the DS^p^^.^ from the data portion of the 

message and feeds the data portion of the message, {[TID SP _ EC * PLAIN TEXT EC *Skey EC (RN SP . 
ec* STD EC * AI EC *TA)] *DS EC 

-Private-Key 

[TID SP . M *PLAIN TEXT M *Skey M (RN SP . 

M *STD M *AI M *TA)]} into a one-way hash algorithm to calculate the message digest MD A M of 

35 this message. The SP separates the data portion of the message, i.e., TID SP . M , PLAIN 

TEXT M ,CRYPTO M , DS^,,^, (TID SP . EC * PLAIN TEXT^^RYPTO^^DSecp^.^. The 
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SP decrypts 310 the DS M _ Pnvate _ Key using the merchant's public key and compares the newly 
recovered message digest MD M with the message digest just calculated MD A M (from 306). If 
MD A M and MD M are not equal, the message has been corrupted and is rejected 314. If 
MD A M and MD M match, then the SP decrypts 3 16 the encrypted portion of the message using 
the session key Skey M (of 210) it assigned to the merchant during the KE phase and recovers 
the data fields contained in the encrypted portion. The SP compares 318 the random number 
RN SP _ M the merchant sends back in the message with the message the SP sent to the merchant 
originally, RN SP _ M (from 208). If the random numbers are not equal, then the merchant has 
failed the mutual authentication test and the message is rejected 320. 

In addition, the SP will verify the EC's account information AI EC and the transaction data 
such as the transaction amount TA. The message is rejected 320 if the AI is no longer valid. 
It is also rejected when the TA from the EC and the TA from the merchant do not match. 
There may be other conditions for invalidating a message. If the account information AI EC 
and the transaction are valid, then the SP goes on to verify the EC portion of the message. 

As with the merchant's message, the SP first separates 322 the DS EC4We _ Key from the 

EC's message and feeds the data portion of the EC's message, (TID SP _ EC *PLAIN 

TEXT EC *CRYPTO EC ) into a one-way hash algorithm to calculate the message digest MD A EC 

of the EC message. The SP separates the data portion of EC's transaction request, TID SP _ EC? 

PLAIN TEXT EC , CRYPTO EC , DS^^. The SP decrypts 324 DS^^ using EC's 

public key PK EC and recovers MD EC . The SP compares 326 the recovered MD EC with MD A EC . 

If MD A EC and MD EC are not equal, the message has been corrupted and is rejected 328. If 

MD A EC and MD EC match, then the SP decrypts 330 the encrypted portion of the EC message 

using the session key Skey EC (of 1 86) it assigned to the EC during the KE phase and recovers 

the data fields contained in it. The SP compares 332 the random number RN SP _ EC the EC 

sends back in the message with the random number RN SP _ EC it sent out to the EC originally (in 

184). If the random numbers are not equal, then the EC has failed the mutual authentication 

test and the message is rejected 334. The SP will verify the merchant's account information 

AI M and the transaction data such as the transaction amount TA and will reject the message 

when the account information is invalid or when the transaction data does not meet the SP's 
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criterion 334. Once the integrity and authenticity of the overall message has been established, 
the SP can process the data contained in the message and send a response message back. The 
random number that is sent back in this message completes the mutual authentication 
between the SP and the merchant, and between the SP and the EC. After this message, no 
exchange of random numbers will be necessary. The SP can chooses to use the random 
number as the transaction identification number which the merchant and the EC will use in all 
subsequent messages that they send to the SP. 

As before, the response message contains information for both the EC and the merchant. 
To format the transaction response message for the EC, the SP generates the response data 
for the EC, Response Datas P _ EC 338, and encrypts 336 it using the session key Skey EC assigned 
to the EC. Only sensitive data is encrypted. Non-sensitive response data is included in the 
plain text. The cryptogram CRYPTO SP „ EC , i.e., E Skey . EC (Response Data^), is combined 340 
with the transaction identification number TID SP _ EC 342 that the SP assigned to the EC (from 
194) and the plain text that the SP has for EC 344, if any, to form the data portion of the 
response message for the EC, i.e., TID SP _ EC *PLAIN TEXT SP _ EC *E Skey _ EC (Response Data SP _ EC ). 
The data portion of the message is fed into a hash algorithm 346 to generate a MD SP _ EC which 
is digitally signed 348 by the SP using the SP's private key 350. The DS SP . Private _ K c yr is 
combined 352 with the data portion of the response message (from 340) to form the complete 
response message for the EC, [TID SP _ EC *PLAIN TEXT SP . EC *E skey . EC (Response Data SP . 
EC )]*DS SP _ Private . Ker To format the transaction response message for the merchant, the SP 
generates the response data for the merchant, Response Data SP _ M 356, and encrypts 354 it 
using the session key Skey M assigned to the merchant (from 210). The cryptogram 
CRYPTO SP . M , is combined 358 with the transaction identification number TID SP _ M assigned to 
merchant 360 (from 218) and the plain text PLAIN TEXT SP . M that the SP has for merchant 
362, if any, to form the data portion of the response message for the merchant, TID SP . 
M * PLAIN TEXT SP _ M *CRYPTO SP _ M . The data is then combined 364 with the completed 
response message for the EC to form the data portion of the response message for both the 
EC and the merchant, [(TID SF „ EC * PLAIN TEXT SP _ EC *E skey _ EC (Response Data SP _ EC )]*DS SP _ Private _ 

Ke /[TID SP _ M *PLAIN TEXT SP . M *E skey . M (Response Data^]. 
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1 The data is then fed into a hash algorithm 366 to generate a MD^ which is digitally 

signed 368 by the SP using the SP's private key 370. The DS SP . Wvate . Key is combined 372 with 
the data portion of the response message for both the EC and the merchant to form the 

5 complete response message for both the EC and the merchant, «{ [TID SP . EC *PLAIN TEXT SP . 
EC *E skey . EC (Response Data SP _ EC )] *DS SP _ Private _ Key } 

*[TrD SP . M *PLAIN TEXT SP . M * E skey . M (Response 
Data SP . M )]»*DS SP . Private . Key . The SP then sends its response message back to the merchant. 
Figure 10 depicts the final format of the transaction response message, 
j o When the merchant receives the message, the merchant first checks 374 the transaction 

identification number, TID SP . M> in the message and makes sure it is valid. If the transaction 
identification number is invalid then the message is rejected 376. If the TID SP . M is valid, then 
the merchant separates the DS^p^^ which was signed by the SP from the data portion of 
j 5 the message, and then feeds the data portion of the transaction response message «{ [TID SP . 
EC *PLAIN TEXTsp.Ec^Es^.EcCResponse Data SP . EC )]*DS S p.p rivate . K ey}*[TID S p. M *PLArN TEXT SP . 
M *E skey . M (Response Data SP . M )]» into a one-way hash algorithm producing a MD A SP . M . The 
merchant separates the data portion of the message into different parts, TID SP . M , PLAIN 
20 TEXT SP . M , CRYPTCw, DS SW)rivate . Key (TID SP . EC *PLAIN TEXT SP . EC *CRYPTO SP . EC *DS SP . 

private-Key) ^ prepares to forward SP's transaction response message to the EC. The merchant 
decrypts 378 the encrypted portion of the SP's message using the session key Skey M assigned 
by the SP during the KE phase and recovers the data fields contained within it. The merchant 
then uses SP's public key, PK SP (froml44), to decrypt the digital signature OSsp^^.,^ to 
recover MD SP . M . The merchant compares 380 the newly hashed MD a sp .m (fr° m 374 ) with the 
recovered MD SP . M . If MD A SP . M and MD SP . M do not match, then the transaction response 
message has been corrupted and is therefore rejected 382. If the message digests match, then 
the merchant starts processing the message. As usual, the EC portion of the transaction 
response message (TID SP . EC *PLAIN TEXT SP . EC !|! CRYPTO S p. EC *DS S p. Private . Key ) is passed to 
EC. 

When the EC receives the transaction response message, the EC first checks 394 the 
35 transaction identification number, TID SP . EC in the message and makes sure it is valid. If the 
transaction identification numbers is invalid, then the message is rejected 396. If the 
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transaction identification number is valid, then the merchant separates the DS^p^^ which 
was signed by the SP, from the data portion of the transaction response message, and then 
feeds the data portion of the EC transaction response message TID SP _ EC * PLAIN TEXT SP- 
EC *E skey _ EC (Response Data SP _ EC ) into a one-way hash algorithm producing MD V EC . The EC 
separates the message into different parts, TID SP _ EC , PLAINT SP _ EC , CRYPTO SP _ EC , DS SP _ Private _ 
Key . The EC decrypts 398 the encrypted portion of SP's message using the session key Skey 
assigned by the SP during the KE phase and recovers the data fields contained within it. The 
EC uses SP's public key (from 120) to decrypt the digital signature DSsp^^ and recovers 
the message digest MD SP _ EC . The merchant compares 400 the newly hashed MD A SP _ EC 394 
with the recovered MD SP „ EC . If MD a sp _ec and MD SP . EC do not match, then the transaction 
response message has been corrupted and is therefore rejected 402. If the message digests 
match, then the EC starts processing the message. 

At the end of the transaction, the EC and the merchant can, if required by the SP, send 
an acknowledgement message to the SP to signal that the response message has been 
correctly received and processed. This acknowledgement data can be included as a part of the 
next message to be sent to the SP, if there are more messages to be exchanged between the SP 
and the merchant and the EC before the transaction ends. Or the acknowledgement data can 
be a message by itself. 

To format the acknowledgement message, the EC first encrypts 404 the sensitive part of 
the acknowledgement data, Acknowledgement Data EC , 406, if any, using the session key, 
Skey EC? thus creating Skey EC (Acknowledgement Data EC ). The EC combines 408 the resulting 
cryptogram with the transaction identification number TID SP . EC 410 assigned by the SP and 
the plain text PLAIN TEXT EC 412, if any. This forms the data portion of EC's 
acknowledgement message, TID SP _ EC * PLAIN TEXT EC * Skey EC (Acknowledgement Data EC ). 
This combined data is then fed into a one-way hash algorithm 414 to generate the MD EC . The 
resulting MD EC is then digitally signed 416 by the EC using the EC's private key 418 to 
generate a DS^m^^. The DS EC . P rivate-K e y is combined 420 with the data portion of the 
message (from 408) to form the complete acknowledgement message for the EC, [TID SP . 
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EC *PLAIN TEXT EC *Skey EC (Acknowledgement Data EC )]*DS BoWvate . Kv . The acknowledgement 
message is then sent to the merchant. 

The merchant goes through the same steps to form his own acknowledgement message. 
To format the acknowledgement message, the merchant first encrypts the sensitive parts of 
the acknowledgement data, Acknowledgement Data M 386, if any using the session key Skey M 
assigned by the SP to merchant, thus creating Skey M (RN SP _ M * Acknowledgement Data^. The 
merchant combines 388 the resulting cryptogram with the transaction identification number 
TID SP _ M 390 assigned by the SP, and the plain text PLAIN TEXT M (from 392), if any. This 
forms the data portion of the merchant's acknowledgement message, TID SP _ M *PLAIN 
TEXT M * Skey M (RN SP _ M * Acknowledgement Data M ). This data portion is further combined 
422 with the acknowledgement message received from the EC to form the data portion of the 
combined acknowledgement message for the SP, {[TID SP _ EC *PLAIN 
TEXT EC *Skey EC (Acknowledgement Data EC )]*DS BC . ftivBte . Kv } * [TID SP VPLAIN 
TEXT M *Skey M (Acknowledgement Data M )]. The merchant feeds the data portion of the 
combined acknowledgement message for the SP into a one-way hash algorithm to generate 
the message digest MD M . The resulting MD M is then digitally signed by the merchant using 
the merchant's private key 428 to generate DS M . Private . Key 426. The DS M . MvatelKfiy is combined 
430 with the data portion of the message (from 422) to form the final combined 
acknowledgement message of the EC and the merchant designated for the SP, «{[TID SP . 
EC *PLAIN TEXT EC *Skey EC (Acknowledgement Data EC )] *DS E(>Private . Key } * [TID SP _ M * PLAIN 
TEXT M *Skey M (Acknowledgement Data M )]»*DS M . Private _ Ker This message is then sent to the 
SP. Figure 1 1 depicts the final format of the transaction acknowledgement message. 

TID SP _ M is the transaction identification number assigned by the SP to the merchant 

(from 218) and TID SP . EC is the transaction identification number assigned by the SP to the EC 

(from 194). Upon receiving the transaction acknowledgement message, the SP checks 432 

the two transaction identification numbers, TID SP _ M and TID SP . EC , sent by the EC and the 

merchant and makes sure they are valid. When either TID SP . M or TID SP . EC is found invalid, 

then the message is rejected 434. If the transaction identification numbers are both valid, 

then the SP proceeds to separate the DS M _ Pnvate _ Key from the combined acknowledgement 
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message and feeds the data portion of the combined acknowledgement message «{[TID SP . 
EC *PLAINTEXT EC *Skey EC (AclaiowledgementData EC )]*DS EC .p rivate . Key }nTID S p. M *PLAm 
TEXT M *Skey M (Acknowledgement Data M )]» into a one-way hash algorithm to calculate the 
message digest MD A M of this message. The SP separates the data portion of the message, 
TID SP . M , PLAIN TEXT M , CRYPTO M , DS M 

-Private-Key 

(TID SP _ EC *PLAIN 

TEXT EC * CR YPTO EC ) * D S EC _ Private _ Key . The SP decrypts 436 the DS^^ using the 
merchant's public key PK M and compares the recovered message digest MD M 432 with the 
message digest just calculated MD A M 436. If MD A M and MD M are not equal, then the 
message has been corrupted and is rejected 440. If MD A M and MD M match, then the SP 
decrypts 442 the encrypted portion of the merchant's acknowledgement message using the 
session key Skey M (from 210) that it assigned to the merchant during the KE phase and 
recovers the acknowledgement data contained within it. 

The SP separates 444 the DS EC _ Pnvate _ Key from the EC's acknowledgement message and 
feeds the data portion of the EC's acknowledgement message, TID SP _ EC *PLAIN 
TEXT EC *CRYPTO EC , into a one-way hash algorithm to calculate the message digest MD A EC 
of this message. The SP separates the data portion of the EC's acknowledgement message, 
TID SP _ EC , PLAIN TEXT EC , CRYPTO EC5 D 8^^. The SP decrypts 446 the DS EC _^ vate _ Key 
using the EC's public key PK EC and compares 448 the recovered MD EC with the message 
digest just calculated MD A EC 444. If the message digests are not equal, then the message has 
been corrupted and is rejected 450. If MD A EC and MD EC match, then the SP decrypts 452 the 
encrypted portion of the message using the session key Skey EC (from 186) that it assigned to 
the EC during the KE phase and recovers the acknowledgement data contained within it. 
This completes the processing of the transaction phase of the transaction 454. 

Throughout the transaction, in a preferred embodiment, the EC works with interface 
software provided by Internet browser software such as the Microsoft Explorer or Netscape 
Navigator. In a typical session, the cardholder points his browser to the merchant's URL and 
orders goods or services from the merchant. At the time of payment, the browser will invoke 
the EC interface software, which can be built into the browser or included as a plug-in or add- 
on software component, and allow the transaction to proceed. The cardholder can point his 
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browser to the URL of any SP member. 

The two-phased transaction described in figure 6A-6Q above is just a specific case of 
applying the two-phased key-exchange-transaction model. In the two-phased transaction 
described in figures 6A-6Q, the number of parties involved in the transaction is three: the EC, 
the merchant and the SP. The two-phased key-exchange-transaction model is similarly 
applicable to cases where the number of parties involved varies from two to many. In a 
transaction that involves more than three parties, there is only one party that plays the role of 
the SP. All other parties use the public key of the selected SP to perform the initial key 
exchange and use session keys and transaction Ids assigned by the SP to carry out the 
transaction. 

The two-phased key-exchange-transaction model is applicable to organization schemes 
wherein: (1) the participants can be arranged with possible routers in series with the service 
provider; or (2) the participants can be arranged with possible routers in a hierarchical 
organization. These additional organization schemes may involve routers, which route 
messages to the next level. A level of a hierarchy may be composed of any number of 
participants and/or routers. The next level is the next participant or router that is next in the 
sequence or hierarchy. In a hierarchical organization scheme, the next level includes all 
possible next participants and routers. For the hierarchical organization scheme, the SP 
establishes the criterion for determining the next participant or router to which a message is 
sent. 

A router is a gateway/conduit, which collects the messages from a previous level and 
performs some processing on the messages according to an SP's requirements such as 
combining them, and then forwards the messages to the SP. Each participant need only form 
his own message (data and digital signature) and send it to the next level. A participant 
combines all the messages he receives with his own message and digitally signs the combined 
message before sending it to next level. In the hierarchical organization's simplest form, 
there is only one message router, which collects messages from all the other participants and 
sends the combined message to the SP. 

In the series organization, an originator of a transaction is in series with routers and/or 
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participants who in turn are in series with a service a service provider 60. In the preferred 
embodiment of the invention, each element shown in figure 12 is a participant. In an 
alternative embodiment of the invention, any intermediate element between the originator and 
the SP can be a router. 

An originator conducts a transaction with participants 1 100, 1 120, 1 140 andl 160 and a 
service provider that have been arranged in series as shown in Figure 12. This is similar to 
the three-party scenario described in figures 6A-6Q except for the fact that now there is more 
parties involved. Note participants 3,4,5,6 ... n-2 that have been arranged in series 1 180. 
Each of the participants prepares his own message, incorporates it with the message he 
receives from a prior participant, if any, appends a digital signature with the message, and 
then sends it to the next participant in the line. The combined message is eventually sent to 
the SP and the SP forms the response message accordingly and sends it back through the 
same path the original request message has traveled. 

Figure 13 shows elements arranged in a hierarchical organization scheme, where each 

element, Xj j to Xj n (n= 1, 2, 3, ...) 1200, is a participant of the transaction and not a 

message router, and each element, Xj^ (j = 2, 3, 4, k = 1, 2, 3, ...m; m is a variable of type 

n; m may be a different value for different levels of a hierarchy) 1210, can either be a 

participant or a router. The upward pointing bold arrow represents sending a request message 

1220. The downward pointing arrow represents sending a response message 1230. 

Each participant collects messages from a number of participants he is responsible for 

and, after combining the messages with his own and forming a new message, sends the new 

message to the next level. A hierarchical organization scheme may include only one 

participant to as many as is required (The most regressive case of the hierarchical scheme is 

one participant and one service provider). Eventually, at the last element before the service 

provider, X a l where a is of type n, all messages are combined into one message 1240, which 

is then sent to the SP 60. Again, the SP forms the response message and sends it back 

through the same route. 

In the case when the SP is not directing the transaction, the members are conducting the 
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transaction among themselves using the session key generated by the SP. A transaction can 
occur between two or more members. When there are more than two members involved in 
the transaction, the messages can flow from member to member in any order. A member 
sends a transaction request message and receives a transaction response message. A member 
does not necessarily have to receive a transaction response message from the same member 
that he sent the transaction request message. For example, three members in a transaction can 
be organized in a ring and send messages around the ring. A first member can send a 
transaction request message to a second member who in turn sends a transaction request 
message and a transaction response message to third member. The third member sends a 
transaction request message and a transaction response message to the first member, and the 
first member sends a transaction response message to a second member. A member receiving 
a transaction request message creates a transaction response message, which eventually will 
be sent to the member who sent the transaction request message. 

During the key exchange phase, the SP obtains the public keys of all the transaction 
participating members. The SP sends to each participating member, the other members* 
public keys prior to the participating members conducting a transaction among them. The 
transaction request messages and the transaction response message include plain text, if any, a 
cryptogram, and a digital signature of the sending party. 

In the case when the SP needs to act as the surrogate-certificate for the EC and/or the 
merchant in order to deal with a certificate-based external system, the SP shields the EC 
and/or the merchant from the operation of the external interface. The SP only returns to the 
EC and/or the merchant, the information needed to complete the transaction with the EC 
and/or the merchant. 

While there have been described herein what are considered to be preferred and 
exemplary embodiments of the present invention, other modifications of the invention shall 
be apparent to those with ordinary skill in the art. Therefore, it is desired to be secured in the 
appended claims all such modifications and extensions as fall with within the true spirit and 
scope of the invention. The invention is to be construed as including all embodiments thereof 
that fall within the scope of the appended claims and the invention should only be limited by 
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the appended claims below. In addition, one with ordinary skill in the art will readily 
appreciate that other applications may be substituted for those set forth herein without 
departing from the spirit and scope of the present invention. 
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What is claimed: 

1 . A system for electronic transactions comprising: 
an electronic card having, 

a cryptographic service for encryption and decryption, 
a data area for storing cardholder information, and 
a data area for storing service provider information; 
a service provider member terminal responsive to activation of the electronic card; and 
a service provider terminal in communication with the service provider member terminal, 
the service provider terminal decrypting communication from the service provider member 
terminal and encrypting communication to the service provider member terminal, the service 
provider member terminal encrypting communication to the service provider terminal and 
decrypting communication from the service provider terminal. 

2. The system of claim 1 wherein the electronic card is a physical card. 

3. The system of claim 1 further comprising software having the electronic card. 

4. The system of claim 1 wherein the electronic card further comprises a card 
operating system for loading and updating cardholder information, changing access conditions, 
and managing the service provider data area. 

5. The system of claim 1 wherein the electronic card performs external 
communication read/write operations, and communication protocol handling. 

6. The system of claim 1 wherein the electronic card further comprises software to 
manage the electronic card. 

7. The system of claim 1 wherein the electronic card further comprises application 
software. 
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8. The system of claim 1 wherein the electronic card further comprises applets. 

9. The system of claim 1 further comprising an external system wherein the service 
provider terminal communicates with the external system. 

10. The system of claim 1 wherein the data area for storing service provider 
information includes at least one service provider record, each service provider record 
comprising: 

a name field indicating the service provider; 
at least one key value; 

a key-type indication indicating the type of the key value; and 

an account information field containing information unique to each service provider. 

1 1 . The system of claim 1 0 wherein the service provider record further comprises 
an instrument-type indication indicating the type of instrument a service provider supports. 

12. The system of claim 10 wherein the service provider record further comprises an 
access condition, which a user must satisfy to gain access to the service provider information. 

13. A method of conducting an electronic transaction using an electronic card 
comprising: 

formatting a key exchange request message at a member; 

sending the key exchange request message from the member to a service provider; 
generating a session key at the service provider; 

formatting a key exchange response message including the session key at the service 
provider; 

sending the key exchange response message from the service provider to the member; 

and 

using the session key to conduct a transaction. 
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14. A method of conducting an electronic transaction using an electronic card 
comprising: 

o 

formatting a key exchange request message at a member, the key exchange request 
message has a member challenge for the service provider; 

sending the key exchange request message from the member to a service provider; 
generating a session key at the service provider; 

formatting a key exchange response message including the session key at the service 
provider, the key exchange response message has a response for the member challenge and a 
service provider challenge for the member and sending it to the member; 

formatting by the member a response for the service provider challenge and sending it to 
the service provider; and 

using the session key to conduct a transaction. 

15. The method of claim 13 or 14 wherein the step of using the session key to 
conduct a transaction comprises the steps of: 

formatting by a member a transaction request message using the session key, the 
transaction request message including a digital signature of the member, and sending the 
transaction request message to the service provider; and 

formatting at the service provider, a transaction response message for the member using 
the session key, the transaction response including a digital signature of the service provider, and 
sending the transaction response message to the member. 

1 6. The method of claim 1 5 wherein the member encrypts, using the session key 
assigned to him by the service provider, his account information, the transaction amount and 
sensitive transaction data in his transaction request message, the sensitive transaction data being 
information that is accessible only to the service provider. 

1 7. The method of claim 1 5 wherein the member includes plain text in his transaction 
request message. 
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1 8. The method of claim 1 5 wherein the member includes the transaction 
identification assigned to him by the service provider, in his transaction request message. 

19. The method of claim 15 wherein the member includes a response to a service 
provider challenge in his transaction request message. 

20. The method of claim 15 wherein the service provider encrypts the response data 
for the member using member's session key and include the cryptogram as part of its transaction 
response message to the member. 

21 . The method of claim 1 5 wherein the service provider includes plain text in its 
transaction response message to the member. 

22. The method of claim 1 5 wherein the service provider includes member's 
transaction identification in his transaction response message to the member. 

23 The method of claim 1 5 further comprises the steps of: 
formatting at the member, using the session key, a transaction acknowledgment message, 
including a digital signature of the sending member, and sending the transaction 
acknowledgment message to the service provider. 

24. The method of claim 1 5 wherein the member encrypts, using the session key 
assigned to him by the service provider, his acknowledgment data in his acknowledgment 
message. 

25. The method of claim 15 wherein the member includes plain text in his 
acknowledgment message. 

26. The method of claim 1 5 wherein the member includes the transaction 
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identification assigned to him by the service provider, in his acknowledgment message. 

27. The method of claim 15 wherein the member chooses to encrypt sensitive 
information in the transaction acknowledgment message, the sensitive information being 
information that is accessible only to the service provider. 

28. The method of claim 13 or 14 of conducting a key exchange comprising: 
generating a member challenge by the member; 

encrypting by the member the member challenge using the service provider's public key 
and generating a first cryptogram; 

formatting by the member a key exchange request message including the first cryptogram 
and member's public key; 

singing digitally by the member the key exchange request message; 

sending the digitally signed key exchange request message to the service provider; 

generating by the service provider a service provider challenge; 

generating by the service provider a session key; 

encrypting by the service provider the service provider challenge and the session key 
using the member's public key and generating a second cryptogram; 

formatting by the service provider a key exchange response message including the 
second cryptogram and the response to member challenge; 

signing digitally by the service provider the key exchange response message; 

sending digitally signed key exchange response message to the member; 

encrypting by the member the member response for the service provider challenge using 
the session key and generating a third cryptogram; 

attaching the third cryptogram to the next message going from the member to the service 
provider; 

signing digitally by the member the next message going from the member to the service 
provider; and 

sending the next message going from the member to the service provider to the service 
provider. 
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29. The method of claim 28 wherein the member uses different pairs of private and 
public keys for different transactions in the messages to communicate with the service provider. 

30. The method of claim 28 wherein the key exchange request message and key 
exchange response message contain plaintext 

3 1 . The method of claim 28 wherein the member chooses to encrypt his own public 
key using the service provider's public key in the key exchange request message. 

32. The method of claim 28 wherein the member and service provider chooses to 
encrypt sensitive information in the key exchange request message and the key exchange 
response message, the sensitive information being information that is accessible only to the 
service provider and the corresponding member. 

33. The method of claim 28 wherein the service provider encrypts the response to the 
member challenge as part of the second cryptogram. 

34. The method of claim 28 wherein the service provider encrypts transaction 
identification as part of the second cryptogram. 

35. The method of claim 28 wherein the service provider includes a transaction 
identification as part of the plain text in the key exchange response message. 

36. The method of claim 34 wherein the member uses the transaction identification in 
the next message going from the member to the service provider. 

37. The method of claim 35 wherein the member uses the transaction identification in 
the next message going from the member to the service provider. 
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38. The method of claim 13 or 14 of conducting a key exchange between two 
members and a service provider comprises the steps of: 

sending a key exchange request message from the first member to a second member; 

combining at the second member, a second member key exchange request message with 
the first member's key exchange request message and sending the combined key exchange 
request message, signed by the second member, to a service provider; 

formatting a key exchange response message at the service provider including the 
session key for the first member, signing the response message, formatting a key exchange 
response message including the session key for the second member, combining the key exchange 
response messages into a combined key exchange response message, signing the combined key 
exchange response message, and sending the combined key exchange response message to the 
second member; and 

separating at the second member, the key exchange response message for the second 
member from the key exchange response message for the first member, and forwarding the key 
exchange response message for the first member to the first member. 

39. A method of claim 13 or 14 wherein the step of conducting a transaction between 
two members and a service provider comprising: 

formatting by a first member, using the first member's session key, a transaction request 
message, the transaction request message including a digital signature of the first member, and 
sending the transaction request message to a second member; and 

formatting by the second member, using the second member's session key, a transaction 
request message; 

combining by the second member, the second member transaction request message with 
the first member transaction request message, the combined transaction request message 
including a digital signature of the second member, and sending the combined transaction request 
message to a service provider; 

formatting by the service provider, using the first member's session key, a transaction 
response message for the first member, including a digital signature of the service provider; 

formatting by the service provider, using the second member's session key, a transaction 
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response message for the second member; 

combining the transaction response message for the first member with the transaction 
response message for the second member and forming a combined transaction response message, 
the combined transaction response message including a digital signature of the service provider; 

sending the combined transaction response message to the second member; 

separating at the second member, the transaction response message for the first member 
from the transaction response message for the second member; 

forwarding by the second member the transaction response message for the first member 
to the first member. 

40. The method of claim 39 further comprises the steps of: 

formatting at a first member, using the first member's session key, an acknowledgment 
message, the acknowledgment message including a digital signature of the first member, and 
sending the acknowledgment message to a second member; and 

formatting at the second member, using the second member's session key, an 
acknowledgment message, combining the second member acknowledgment message with the 
first member acknowledgment message and forming a combined acknowledgment message, the 
combined acknowledgment message including a digital signature of the second member, and 
sending the combined acknowledgment message to the service provider. 

41. The method of claim 13 or 14 of conducting a key exchange between multiple 
members and a service provider arranged in series comprising the steps of: 

formatting a key exchange request message at a first member; 
sending the key exchange request message from the first member to a second member where the 
second member is a message router or participating member; 

sending a key exchange request message from the second member to a next member, if 
the second member is a message router; 

combining the second member's key exchange request message with the first member's 
key exchange request message and sending the combined key exchange message to the next 
member if the second member is a participating member; 
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sending the combined key exchange request message to the next member if the current 
member is a message router; 

combining a current member's key exchange request message with a previous member's 
key exchange request message and sending the combined key exchange request message to a 
next member, if the current member is a participating member; 

sending the combined key exchange request to a service provider if the current member is 
the last participating member or message router; 

generating at the service provider different session keys for different participating 
members; 

formatting, by the service provider, into one message, a key exchange response message 
including the different session keys for different participating members and sending the 
combined key exchange response message in reverse order of the path for sending the combined 
key exchange request to the service provider; and 

separating, by every participating member, the key exchange response message for itself 
from the key exchange response messages for the other participating members, and forwarding 
the remaining key exchange response messages to the other participating members in reverse 
order of the path for sending the combined key exchange request to the service provider, until the 
first member receives its key exchange response message. 

42. The method of claim 13 or 14 of conducting a transaction using session keys 
between multiple members and a service provider arranged in series comprising the steps of: 
formatting a transaction request message at a first member; 

sending a transaction request message from the first member to a second member where 
the second member is a message router or participating member; 

sending the transaction request message from the second member to a next member, if 
the second member is a message router; 

combining the second member's transaction request message with the first member's 
transaction request message and sending the combined transaction message to the next member if 
the second member is a participating member; 

sending the combined transaction request message to the next member if the current 
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member is a message router; 

combining a current member's transaction request message with a previous member's 
transaction request message and sending the combined transaction request message to a next 
member, if the current member is a participating member; 

sending the combined transaction request to a service provider if the current member is 
the last participating member or message router; 

formatting, by the service provider, into one message, a transaction response message and 
sending the combined transaction response message in reverse order of the path for sending the 
combined transaction request to the service provider; and 

separating, by every participating member, the transaction response for itself from the 
transaction response for the other participating members, and forwarding the remaining 
transaction response to the other participating members in reverse order of the path for sending 
the combined transaction request message to the service provider, until the first member receives 
its transaction response. 

43. The method of claim 13 or 14 of conducting a key exchange between multiple 
members and a service provider arranged in a hierarchical organization comprising the steps of: 
formatting a key exchange request message at a first member; 

sending the key exchange request message from the first member to a next member Xj,k 

(j=2,3,4 ; k=l,2,3 m; m is a variable of type n; n^l,2,3...; m can be different values of j) if 

the second member is a message router; 

combining a second member's key exchange request message with the first member's 
key exchange request message and sending the combined key exchange request message to a 
next member Xj,k if the second member is a participating member; 

sending the combined key exchange request message to the next member Xj,k if a 
current member Xj,k is a message router; 

combining a current member Xj,k's key exchange request message with a previous 
member's key exchange request message and sending the combined key exchange request 
message to the next member Xj,k, if the current member Xj,k, is a participating member; 

sending the combined key exchange request to a service provider if the current member is 
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the last participating member; 

generating at the service provider different session keys for different participating 
members; 

formatting, by the service provider, into one message, a key exchange response message 
including the different session keys for different participating member and sending the combined 
key exchange response message in reverse order of the path for sending the combined key 
exchange request to the service provider; and 

separating, by every participating, the key exchange response message for itself from the 
key exchange response messages for the other participating members in reverse order of the path 
for sending the key exchange request to the service provider, until the first member receives its 
key exchange response message. 

44. The method of claim 13 or 14 of conducting a transaction using session keys 
between multiple members and a service provider arranged in a hierarchical organization 
comprising the steps of: 

formatting a transaction request message at a first member; 

sending the transaction request message from the first member to a next member Xj,k (j 
= 2, 3, 4, . . . ; k = 1, 2, 3, . . . m; m is a variable of type n; n= 1, 2, 3, . . . ; m can be different 
values of j) if the second member is a message router; 

combining a second member's transaction request message with the first member's 
transaction request message and sending the combined transaction request message to a next 
member Xj,k if the second member is a participating member; 

sending the combined transaction request message to the next member Xj,k if a current 
member Xj,k is a message router; 

combining a current member Xj,k's transaction request message with a previous 
member's transaction request message and sending the combined transaction request message to 
the next party Xj,k if the current member Xj,k a participating member; 

sending the combined transaction request to a service provider if the current member is 
the last participating member or message router; 

formatting, by the service provider, into one message, a transaction response message for 
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1 each participating member and sending the combined transaction response message in reverse 
order of the path for each participating member and sending the combined transaction request to 
the service provider; and 

^ separating, by every participating, transaction response message for itself from the 

transaction response messages for the other participating members in reverse order of the path 
for sending the transaction request to the service provider, until the first member receives its 
transaction response message. 

^ 45 . The method of claim 1 3 or 1 4 of conducting a key exchange between two 

members and a service provider comprises the steps of: 

sending a key exchange request message from the first member to a second member; 
combining at the second member, a second member key exchange request message with 
15 the first member's key exchange request message and sending the combined key exchange 
request message, signed by the second member, to a service provider; 

generating at the service provider a session key used for both the first member and the 
second member; 

20 formatting a key exchange response message at the service provider including the 

session key for the first member, signing the response message, formatting a key exchange 
response message including the session key for the second member, combining the key exchange 
response messages into a combined key exchange response message, signing the combined key 

25 exchange response message, and sending the combined key exchange response message to the 
second member; and 

separating at the second member, the key exchange response message for the second 
member from the key exchange response message for the first member, and forwarding the key 
exchange response message for the first member to the first member. 

30 

46. The method of claim 13 or 14 of conducting a key exchange between multiple 
members and a service provider arranged in series comprising the steps of: 
formatting a key exchange request message at a first member; 

sending the key exchange request message from the first member to a second member 
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where the second member is a message router or participating member; 

sending a key exchange request message from the second member to a next member, if 
the second member is a message router; 

combining the second member's key exchange request message with the first member's 
key exchange request message and sending the combined key exchange message to the next 
member if the second member is a participating member; 

sending the combined key exchange request message to the next member if the current 
member is a message router; 

combining a current member's key exchange request message with a previous member's 
key exchange request message and sending the combined key exchange request message to a 
next member, if the current member is a participating member; 

sending the combined key exchange request to a service provider if the current member is 
the last participating member or message router; 

generating at the service provider a session key for the participating members; 

formatting, by the service provider, into one message, a key exchange response message 
including the session key for the participating members and sending the combined key exchange 
response message in reverse order of the path for sending the combined key exchange request to 
the service provider; and 

separating, by every participating member, the key exchange response message for itself 
from the key exchange response messages for the other participating members, and forwarding 
the remaining key exchange response messages to the other participating members in reverse 
order of the path for sending the combined key exchange request to the service provider, until the 
first member receives its key exchange response message. 

47. The method of claim 13 or 14 of conducting a key exchange between multiple 
members and a service provider arranged in a hierarchical organization comprising the steps of: 
formatting a key exchange request message at a first member; 

sending the key exchange request message from the first member to a next member Xj,k 

(j=2,3,4 ; k=l,2,3 m; m is a variable of type n; n=l,2,3...; m can be different values of j) if 

the second member is a message router; 
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1 combining a second member's key exchange request message with the first member's 

key exchange request message and sending the combined key exchange request message to a 
next member Xj,k if the second member is a participating member; 

sending the combined key exchange request message to the next member Xj,k if a 
current member Xj,k is a message router; 

combining a current member Xj,k's key exchange request message with a previous 
member's key exchange request message and sending the combined key exchange request 
message to the next member Xj,k, if the current member Xj,k, is a participating member; 
1 ° sending the combined key exchange request to a service provider if the current member is the last 
participating member or message router; 

generating at the service provider a session key for the participating members; 
formatting, by the service provider, into one message, a key exchange response message 
1 5 including the session key for the participating member and sending the combined key exchange 
response message in reverse order of the path for sending the combined key exchange request to 
the service provider; and 

separating, by every participating, the key exchange response message for itself from the 
20 key exchange response messages for the other participating members in reverse order of the path 
for sending the key exchange request to the service provider, until the first member receives its 
key exchange response message. 

25 48. The method of claim 38 wherein the service provider provides each member 

involved in a transaction with other member's public keys. 

49. The method of claim 41 wherein the service provider provides each member 
involved in a transaction with other member's public keys. 

30 

50. The method of claim 43 wherein the service provider provides each member 
involved in a transaction with other member's public keys. 

3$ 5 1 m xhe method of claim 45 wherein the service provider provides each member 
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involved in a transaction with other member's public keys. 

52. The method of claim 46 wherein the service provider provides each member 
involved in a transaction with other member's public keys. 

53 . The method of claim 47 wherein the service provider provides each member 
involved in a transaction with other member's public keys. 
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A CRYPTOGRAPHIC SYSTEM AND METHOD 
FOR ELECTRONIC TRANSACTIONS 

ABSTRACT OF THE DISCLOSURE 

An electronic transaction system, which facilitates secure electronic transactions among 
multiple parties including cardholders, merchants, and service providers (SP). The system 
involves electronic cards, commonly known as smart cards, and their equivalent computer 
software package. The card mimics a real wallet and contains commonly seen financial or non- 
financial instruments such as a credit card, checkbook, or driver license. A transaction is 
protected by a hybrid key cryptographic system and is normally carried out on a public network 
such as the Internet. Digital signatures and challenges - responses are used to ensure integrity 
and authenticity. The card utilizes secret keys such as session keys assigned by service providers 
(SPs) to ensure privacy for each transaction. The SP is solely responsible for validating each 
participant's sensitive information and assigning session keys. The system does not seek to 
establish a trust relationship between two participants of a transaction. The only trust 
relationship needed in a transaction is the one that exists between individual participants and the 
SP. The trust relationship with a participant is established when the SP has received and 
validated certain established account information from that particular participant. To start a 
transaction with a selected SP, a participant must have the public key of the intended SP. Since 
the public key is openly available, its availability can be easily established by the cardholder. 
The SP also acts as a gateway for the participants when a transaction involves interaction with 

external systems. 
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TID SP . EC *PLAINTEXT S p. E c*E E c.PK(RNsp-EC*RN E c*Skey E c*STD S p. EC ) 



•196 



SERVICE PROVIDER HASHES AND PRODUCES A MESSAGE DIGEST:H[TID SP _ EC 
*PLAINTEXT S p. EC *E E c.p K (RNsp.EC !,: RN E c*Skey EC *STD SP . E c)]=MD S p. E c 








( — -198 

r 


READ SP'S 
Private Key 


-► 


USE SERVICE PROVIDER'S DIGITAL SIGNATURE 
GENERATOR : E S p.p rivate .Key(MD S p. EC )=DS S p.p r i vate . Key 



202 



200 



SERVICE PROVIDER COMBINES : 
[TID S p. E c*PLAINTEXT S p. E c*E E c.PK(RN S p. E c*RN E c*Skey EC *STD EC )]*DS S p 

-Private-Key 



( 204 



TO STEP 222 FIG. 6F 



208 



FROM STEP 178 FIG. 6D 



RANDOM NUMBER GENERATOR 
SP GENERATES RN TO M: RN SP . M 



MERCHANT'S RANDOM 
NUMBER (SEE 148) DECRYPTED 
BY SP (SEE170): RN M 



tz: 



212 



X 



210 



SP GENERATES ONE SESSION 
KEY FOR MERCHANT : Skey M 



SP'S SENSITIVE 
TRANSACTION DATA 
TO MERCHANT: STD SP . M 



214 



TO STEP 206 FIG. 6F 



FIG. 6F 

FROM STEPS 208,210, 212,214 FIG 6E 



X 



206 



SP ENCIPHER: USE MERCHANT'S PUBLIC KEY 
E M -PK(RNsp-M*RNM*Skey M *STD S p. M ) 



SP assigns a Transaction 
Identification Number to merchant: 
TID SP . M ^Transaction ID SP . M 



218 



SP'S PLAIN TEXT TO MERCHANT: 
PLAIN TEXT SP _ M 



220 



SERVICE PROVIDER COMBINES PLAIN TEXT AND CRYPTOGRAM 
TID S p. M *PLAINTEXT S p.M*E M -PK(RNsp.M*RNM*Skey M *STD S p. M ) 



FROM STEP 204 FIG. 6E 



216 



SERVICE PROVIDER COMBINES: [TID SP . EC *PLAIN TEXT SP . EC 

*E EC .pK*(RN S p.Ec*RN E c*Skey EC *STD S p. E c)]*DS S p. Private . Key 
*[TID S p.M*PLAINTEXT SP .M*EM-PK(RNsp-M*RNM*Skey M *STD SP . M )] 



222 



SP HASHES AND PRODUCES A MESSAGE DIGEST : 
H{[TID S p. E c*PLAINTEXT S p. EC *E E c.PK(RNsp. E c*RN E c*Skey E c*STD E c)] 
*DSsp-Private-Key* [TID sp .m*PLAINTEXT sp .m 
*E M .pK(RN SP .M*RN M *Skey M *STD S p. M )]}=MD S p. M 









( — - 224 

r 


READ SP 
Private Key 


-► 


USE SERVICE PROVIDER'S DIGITAL SIGNATURE 
GENERATOR: E S p.p rivate . Key (MD S p. M )-DS SP .p rivate . Key 



228 



226 



SERVICE PROVIDER COMBINES: 
«{[TIDs P .Ec*PLAINTEXTsp. E c*(E EC .pK*RN SP . E c*RN E c*Skey E c*STD S p. E c)] 
*DS SP . Private . Key }*[TID S p. M *PLAINTEXT S p. M 
*E M . PK (RN S p. M *RN M *Skey M *STD SP . M )]»DS S p 

-Private-Key 

=[(TiD SP . EC *PLAIN TEXTsp 

-Private-Key 

*CRYPTO SP . EC )*DS S p.p rivate . Key 
*(TID SP . M *PLAIN TEXT S p.M*CRYPTO SP . M )]*DS S p_p rivate . Key 



230 



-TO STEP 232 FIG. 6G 



SECOND PARTY 
COMPUTER UNIT 
(SERVICE PROVIDER) 



FIG. 6G 

FROM STEP 230 FIG. 6F 



NETWORK 



FIRST PARTY 
COMPUTER UNIT 
(MERCHANT) 




Step 3 in FIG. 2 



(1) Merchant separates the DSsp.pnvatg.Key. (2) Merchant hashes the data portion of 
the SP's KE response message: H[(TID S p. EC *PLATN TEXT S p. E c*CRYPTO S p. EC ) 

*DS SP -Private-Key 

*(TID S p. M *PLAINTEXT SP . M *CRYPTO S p. M )]=MD A M 

(3) Merchant separates the data portion of the SP's KE response message: 

TID SP . M , PLAIN TEXT S p. M , CRYPTO SP . M , 
[(TID SP . EC *PLAINTEXT SP . E c*CRYPTO SP . EC )]*DS SP .p rivate . Key 

(4) Merchant verifies: Dsp.p U biic-Key(DS S p.p rivate .Key)=MD M (Refer to FIG. 5) 



y 236 




NO 


REJECTED 


< ■ 



232 




MERCHANT DECIPHER: D 



Merchant-Private-Key' 



(CRYPTO S p. M ) 



""DMerchant-Private-Key [EMerchant-Public-Key(RNsP-M*RNM*Skey]vi*STDsp. M )] 

Recover RN M , Is RN M identical with RN M in step 148 FIG. 6B? If yes, then 
(1) Merchant forwards SP's KE response message to EC: 
(TIDsp.ec^PLAIN TEXT S p. E c*CRYPTO S p. EC * DS S p. Private . key ) to step 260 FIG. 6H 
(2) Merchant prepares transaction phase of the transaction to step 244 FIG. 6 H 




START OF MERCHANTS 
TRANSA CTION PHASE 



TO STEP 260 FIG. 6H 



TO STEP 244 FIG. 6H 



FIG. 6H 



246 



FROMSTEP240 FIG. 6G 



Random Number SP (see 208) sent 
to Merchant (see 238): RN SP _ M 



Merchant's sensitive transaction 
data to SP: STD M 



250 



248 



MERCHANT'S ACCOUNT 
INFORMATION: AI M 



TRANSACTION 
AMOUNT: TA 



252 



MERCHANT'S ENCIPHIRS: USE SP'S SESSION KEY FOR MERCHANT: 
Skey M (RN SP .M*STD M *AI M *TA)=CRYPTO M 



244 



Transaction Identification Number SP (see 218) 
assigned to merchant (see 232): TID S p_ M 

( 256 | 



Merchant's plain Text 
to SP: PLAIN TEXT^ 



258 



MERCHANT COMBINES: 
TIDsp. M *PLAIN TEXT M *CRYPTO M 



FIRST PARTY 
COMPUTER UNIT 
(MERCHANT) 



254 



TO STEP296 FIG. 6 J 



ELECTRONIC CARD 
COMPUTER UNIT 
(ORIGINATOR) 



FROM STEP240 FIG. 6G 




Step 4 in FIG. 2 



(1) EC separates the DS S p.private-Key> and hashes the data portion of the message: 

H(TID SP . E c*PLAINTEXT S p. EC *CRYPTO S p. EC )=MD^ SP . EC 
(2) EC separates: TID SP _ EC , PLAIN TEXT SP . EC , CRYPTO SP . EC , DS.^^ 
(3) EC verifies: D SP . public . Key (DSsp-MvateW^Dsp-Ec (Refer to FIG.5) 




TO STEP266 FIG. 61 



YES 



X 



266 



FIG. 61 

FROMSTEP262 FIG. 6H 

A 



EC'S DECIPHER: DEC-Private-Key( CRYPTO SP-Ec) -D EC-Private-Key 

[ E EC-Public-Key( RN SP-EC* RN EC* Ske yEC* STD sp-Ec)]; And recovers RN EC 




X 



274 



Is RN EC =RN EC 
_ste£ 124 FIG. 6A2 

YES 



X 



270 



REJECTED 



RANDOM NUMBER SP (see 184) 
SENT TO EC (see 266): RN SP . EC 



SENSITIVE TRANSACTION 
DATA EC TO SP: STD EC 

( — -278 | 



START OF ECS TRANSACTION PHASE 



EC'S ACCOUNT INFORMATIONAL 



276 



TRANSACTION 
AMOUNT: TA 



TZT 



280 



EC'S ENCIPHIR: USE SP'S SESSION KEY FOR EC: 
Skey EC (RN SP . EC *STD EC *AI EC *TA)=CRYPTO EC 



272 



Transaction Identification Number SP (see 194) 
assigned to EC (see 260): TID S p. Rr; 



284 



EC's PLAIN TEXT: 
PLAIN TEXT RC 



286 



EC COMBINES: TID EC *PLAIN TEXT EC *CRYPTO EC 



282 



EC HASHES AND PRODUCES A MESSAGE DIGEST: 
H[TID SP . EC *PLAINTEXT EC *CRYPTO EC ]=MD EC 


( — -288 






r 


READ EC'S 
Private Key 




USE EC'S DIGITAL SIGNATURE GENERATOR: 

EEC-Private-Key(MD EC )=DS EC . private . Key 



292 



290 



EC COMBINES: [TID SP . EC *PLAIN TEXT EC 
*Skey EC (P^ SP , EC *STD EC *AI BC *TA)]*DS EC , Private , Key 



294 



-Step 5 in FIG. 2 



TO STEP296 FIG. 6 J 



i 



ELECTRONIC CARD 
COMPUTER UNIT 
(ORIGINATOR) 



FIG. 6 J 



r 



NETWORK 



FROMSTEP294 FIG. 61 



v 



FIRST PARTY 
COMPUTER UNIT 
(MERCHANT) 



FROMSTEP254 FIG. 6H 



MERCHANT COMBINES: 
[TID S p. E c*PLAINTEXT E c*Skey EC (RN S p. E c*STD EC *AI EC *TA)]*DS EC . Private . Key 
*[TIDsp-M*PLAINTEXT M *SkeyM(RN S p. M *STDM*AlM*TA)] 
=(TID SP . EC *PLAIN TEXT E c *CRYPTOec)*DSbc.mv^ 
*(TID S p.m*PLATN TEXT M * CRYPTOm) 



ZZ 



296 



MERCHANT HASHES AND PRODUCES A MESSAGE DIGEST: 
H[(TID SP _ E c*PLAIN TEXT EC *CRYPTO ecp )*DS ec -Private-Key 
*(TID SP - M *PLArN TEXT M * CRYPTO m )]=MD m 



MERCHANT'S 
Private Key 



zz 



ZZ 



298 



USE MERCHANT'S DIGITAL SIGNATURE 
GENERATOR: E M . Pr i vate . Key (MD M )=DSm 

-Private-Key 



302 



ZZ 



300 



MERCHANT COMBINES: 
{[TIDsp- E c*PLArNTEXT EC *Skey E c(RN SP . E c*STD E c*AI E c*TA)]*DS EC .p riV ate-Key 
*[TID S p.M*PLAINTEXTM*Skey M (RN S p.M*STDM*AlM*TA)]}*DS M -Privata-Key 
=[(TID S p. EC *PLAINTEXT EC *CRYPTO E c)*DS EC 

-Private-Key 

*(TID SP . M *PLAIN TEXT M * CRYPTO M )]*DS M . Private . Key 



TZ 



FIRST PARTY 
COMPUTER UNIT 
(MERCHANT) 



Step 6 in FIG. 2 



304 



f NETWORK 



SECOND PARTY 
COMPUTER UNIT 
(SERVICE PROVIDER) 



306 



(I) SP checks TID SP . M and TIDsp^to make sure they are valid (see 218 and 194), 
if one of them is invalid then rejected 308. 0SP separates DS M . Private . Key . 

(3) SP hashes the data portion of the transaction request message obtains MD A M . 

(4) SP separates the data portion of the transaction request message and obtains: 

TID S p. M , PLAIN TEXT M , CRYPTO M; DS M . Private . Key , 

(TID SP . EC *PLAINTEXT E c*CRYPTO E c)*DS E c.p ri vate-Kev 



308 



i 



REJECT 



TID SP . M or TID SP . EC is invalid 



TO STEP 310 FIG. 6K 



FIG. 6K 

FROMSTEPS06 FIG. 6J^1A 



310 



Use PK M to verify the DS M _ Private . Kev , Is MD A M =MD M ? (Refer to FIG. 5) 



X 



314 



REJECT 



NO 



312 



MD A M =MD M ? 




, YES 



316 



Skey M decrypts CRYPTO M , recovers RN SP _ M , RN SP . M =RN SP . M in 208 FIG. 6E? 



318 



REJECT 



.RNgp^M correct? Verify AI M andJTA 
-YES 



322 



(1) SP separates DS EC _ Private _ Key , hashes the data portion of EC's transaction request 
message: H(TID SP . EC *PLAIN TEXT EC *CRYPTO EC )=MD A EC 
(2) SP separates and obtains:TID SP . EC , PLAIN TEXT EC , CRYPTO EC , DS EC . Private . Key 




r >324 


SP uses PK EC to verify DS EC . Private _ Kev , Is MD A EC =MD EC ? (Refer to FIG. 5) 


r 328 no . J 


r ^326 


REJECT 





YES 



>330 



Skey M decrypt CRYPTO EC , recovers RN SP . EC , RN gP . EC =RN SP . EC in 184 FIG. 6D? 




END OF KE PHASE 



338 



SP's Response Data SP . EC to EC 



YES 

_> TO STEP 354 
FIG. 6L 



> 336 



SP USES Skey EC TO ENCRYPT: E skev . EC (Response Data SP . EC )=CRYPTO SP . EC 



Transaction Identification Number SP 
(see 194) assigned to EC: TID SP . EC 

342 



SP'S PLAIN TEXT TO EC: 
PLAIN TEXT SP . EC 

344 



SERVICE PROVIDER COMBINES: TID SP . EC *PLAIN TEXT SP . EC 
*E sk EC (Response Data SP _ EC )=TI D SP _ EC *PLAIN TEXT SP _ EC *CRYPTO SP _ EC 

340 



TO STEP 346 and 352 FIG. 6L 



FIG. 6L 

FROM STEP 340 FIG. 6K. 



SERVICE PROVIDER HASHES AND PRODUCES A MESSAGE DIGEST : 
H[TIDsp-ec*PLAIN TEXTsp^Esk^Response Data SP . EC )]=MD S p. EC 



READ SP'S 
Private Key 



ZZ 



ZZ 



346 



USE SERVICE PROVIDER'S DIGITAL SIGNATURE 
GENERATOR : E S p.p rivate . Key (MD S p. EC )=DS SP 

-Private-Key 



350 



348 



SERVICE PROVIDER COMBINES : 
[TID SP . EC *PLAIN TEXT SP . EC *E Skey . EC (Response Datasp_ EC )]*DS SP _p rivate _ Key 
= (TID SP . EC *PLAIN TEXT S p. E c*CRYPTO SP . EC )*DS SP 

-Private-Key 

7ZZ 



FROM STEP 332 FIG. 6K 



SP's Response Data SP . M to MERCHANT 



ZZ 



356 



352 



SP USES Skey M TO ENCRYPT: E Skey . M (Response Datasp_ M )=CRYPTO SP _M 



ZZ 



Transaction Identification Number SP (see 
218) assigned to Merchant (see 232): TID SP . M 



ZZ 



360 



354 



SP's plain text to merchant: 
PLAIN TEXT SP . M 



ZZ 



362 



SERVICE PROVIDER COMBINES: TID SP . M *PLAIN TEXT SP . M 
*E S key-M(Response Data SP .M)=TID SP . M *PLAIN TEXT SP . M *CRYPTO SP . M 



358 



SERVICE PROVIDER COMBINES: 
[(TID S p. E c*PLAINTEXT S p. EC *E Skey . E c(ResponseData SP . EC )]*DS S p. Private . Key 
*[TID S p. M *PLAIN TEXT S p.M*E Skey . M (Response Data SP . M )] 
=[(TID S p. EC *PLAINTEXT S p. E c*CRYPTO S p. EC )*DS S p 

-Private-Key 

*(TID SP . M *PLAIN TEXT SP . M *CRYPTO SP . M )] 



1_ 



366 



ZZ 



364 



SERVICE PROVIDER HASHES AND PRODUCES A MESSAGE DIGEST : 

H[(TID S p. EC *PLAINTEXT SP . EC *CRYPTO S p. E c)*DSs P . Private .Key 

*(TID S p. M *PLAINTEXT S p.M ;i: CRYPTO S p. 1 v,)l=MD S p.M 



TO STEP 368 FIG. 6M J 



TO STEP 372 FIG. 6M 



FIG. 6M 



FROM STEP 364 FIG. 6L FR0 M STEP 366 FIG. 6L 







READ SP'S 
Private Key 


USE SERVICE PROVIDER'S DIGITAL SIGNATURE 
GENERATOR : E SP . Private . Key (MD SP . M )=DS SP . Private . Key 


r ( 370 i 


r ( 368 


SERVICE PROVIDER COMBINES: 
«{[TID S p. EC *PLAINTEXTsp.EC*Es k ey.Ec(ResponseData SP . EC )]*DS S p.p rivate . Key } 
*[TID S p. M *PLAIN TEXT S p. M *E skey . M (Response Datas P . M )]»*DS S p. Private . Key 
= [(TID S p. EC *PLAINTEXT S p.p rivate .Key*CRYPTO S p. EC )*DS SP . Private . Key 
*(TID SP _ M *PLAIN TEXT S p.M*CRYPTO S p. M )]*DS SP _ Private _ K ey 


1 SECOND PARTY 
1 COMPUTER UNIT 
^ (SERVICE PROVIDER) 




^—372 

/ \^.Step 7 in FIG. 2 


1 FIRST PARTY 
1 COMPUTER UNIT 
^ (MERCHANT) 




NETWORK 

r 


(1) Merchant checks TID SP . M to make sure it is valid (218 and 232), if not rejected 376. 
(2) Merchant separates DS SP _ Private _ Key . (3) Merchant hashes the data portion of the 
message obtains MD A SP . M . (4) Merchant separates the data portion of the message: 

TID S p. M , PLAINTEXTsp-m, CRYPTO SPM , DS^p^^ 
Prepare to forward (TiD SP _ EC *PLAIN TEXT S P-EC*CRYPTO S p_ EC *DS SP _ Private . Key ) 


^ TID^p.m 


is invalid 


( — -374 


REJECTED 
( 376 


(1) Merchant use SP's session key for merchant received and decrypted 238 FIG. 6G: 
D Skey-M( CRYp TO SP . M )=D skey . M [E skey . M (Response Data^)] 
(3) Merchant use SP Publice . Key to verify DS SP . Private . Key (Refer to FIG. 5) 
D SP-Public-Key( DS SP- P rivate-Key) =MD SP-M> When MD SP . M equal to MD A SP . M then, 
send (TID SP . EC *PLAIN TEXT SP . EC *CRYPTO SP . EC *DS SP . Private . key ) to 394 FIG 6N 




( — 378 

r 



▼ 

TO STEP 380 FIG. 6N 



FIG. 6N 



FROM STEP 370 FIG. 6M 





NO 


REJECTED 


< ■ 


( — -382 






Merchant's 
acknowledgement data to SP 
Acknowledgement Data M 

r 



YES 



-386 



Forward SP 's message for EC 

"7 



MERCHANT'S ENCTPHIR: USE SP'S SESSION KEY FOR MERCHANT: 
Skey M (RN SP . M * Acknowledgement Data M )=CRYPTO M 



384 



Transaction Identification Number assigned by 
SP (see 210 ) to Merchant (see 224 ): TID SP . M 

< 390 



Merchant's Plain Text to 
SP: PLAIN TEXT M 

( 392 



MERCHANT COMBINES: TID SP . M *PLAIN TEXT M *CRYPTO 



388 



FIRST PARTY 
COMPUTER UNIT 
(MERCHANT) 



-► TO STEP 422 FIG. 6P 

Merchant forwards SP's message 
for EC; Step 8 in FIG. 2 



ELECTRONIC CARD 
COMPUTER UNIT 
(ORIGINATOR) 




(1) EC checks TIDgp^to make sure it is valid (194, 260). If not valid rejected 396. 
(2) EC separates DS SP . Private . Key . (3) EC hashes the data portion of the message 
obtains MD A SP . EC . (4) EC separates the data portion of the message: 
TID SP . EC , PLAIN TEXT SP . E c, CRYPTO SP . EC , DS SP . Private . Key 



REJECT 



TID SP . EC is invalid 
- 396 



394 



TO STEP 398 FIG. 60 



FIG. 60 



-FROM 394 FIG. 6N 



(1) EC uses SP's session key for EC that received and decrypted in step 
266 FIG. 61: D Skey . EC (CRYPTO S p. EC )=D skey . EC [E Skey . EC (Response Data S p. E c)] 
(2) EC use D S p.p ublic . K ey to verify DS S p-p ri v a te-Key (Refer to FIG. 5) 
l>SP-Pubiic-Key(I>S S p.p rivate . Key )=MD S p. E c, Is MD SP . EC equal to MD A SP . EC ? 



402 



398 



400 



REJECT 




JL 



406 



EC's acknowledgement data to SP 
Acknowledgement Data EC 



r 



404 



YES 



EC'S ENCIPHIR: USE SP'S SESSION KEY FOR EC: 
Skey EC (AcknowledgementData EC )=CRYPTO EC 



Transaction Identification Number assigned 
by SP (see 186) to EC (see 252) :TED S p. E c 



410 



EC'S PLAIN TEXT TO 
SP: PLAIN TEXT EC 



tz 



412 



EC COMBINES: TIDsp. EC *PLAIN TEXT EC *CRYPTO EC 



408 



EC HASHES AND PRODUCES A MESSAGE DIGEST: 
H[TID S p. E c*PLArNTEXT EC *CRYPTO E c]=MD EC 



READ EC'S 
Private Key 



TZ 



414 



USE EC'S DIGITAL SIGNATURE GENERATOR: 

^EC-Private-Key(MDEc) = PS EC .p rivate . Ke y 



418 



416 



EC COMBINES: 

[TID S p. EC *PLArNTEXT EC *Skey EC (AcknowledgementData EC )]*DS Ec .p rivate . Key 



TO STEP 422 FIG. 6P 



-Step 9 in FIG. 2 



420 



ELECTRONIC CARD 
COMPUTER UNIT 
(ORIGINATOR) 



FIG. 6P 



FROM STEP 420 FIG. 60 



network^ 



FROM STEP 388 FIG. 6N 



MERCHANT COMBINES : 

{[TID S p. E c*PLAINTEXT E c*Skey E c(AcknowledgementData E c)]*DS E c.private-Key} 
*[TTD S p. M *PLAIN TEXT M *Skey M (Acknowledgement Data M )] 



422 



MERCHANT HASHES AND PRODUCES A MESSAGE DIGEST: 
H«{[TID S p. E c*PLATN TEXT EC *Skey EC (Acknowle(igement Data EC )] 

*DS E c.p riv ate-Key}*[TID SP . M *PLAIN TEXT M 

*Skey M (AcknowledgementData M )]»=MD M 



READ MERCHANT'S 
Private Key 



424 



USE MERCHANT'S DIGITAL 
SIGNATURE GENERATOR: 

E M-Private-Key ( MD M) =DS M-Private-Key 



428 



426 



MERCHANT COMBINES: 
«{[TID SP . EC *PLAIN TEXT EC *Skey EC (Acknowledgement Data EC )] 
*DS E c.p rivate -Key}*[TIDsp.M*PLArNTEXT M 

*Skey M (AcknowledgementData M )]» !,: DSM.Piivate-Key 
={[(TID S p. E c*PLAINTEXT E c*CRYPTO E c)*DS EC 

-Pnvate-KeyJ 

*(TID sp _m*PLAIN TEXT M *CRYPTO M )}*DS M _ Private _ Key 



FIRST PARTY 
COMPUTER UNIT 
(MERCHANT) 



430 



Step 10 in FIG. 2 



[ 



SECOND PARTY 
COMPUTER UNIT 
(SERVICE PROVIDER) 



TO STEP 432 FIG. 6Q 




FIG. 6Q 

FROM STEP 430 FIG. 6P 





r~432 


(1) SP checks TID SP _ M and TID SP . EC to make sure it is valid (see 218 and 194 ), 
if one of them is not valid then rejected 434. (2) SP separates DS M .private-Key- 

(3) SP hashes the data portion of the message obtains MD A M . 
(4) SP separates the data portion of the message: TID S p-m> PLAIN TEXT M , 

CRYPTO M , DS M . Private .Ke y? (TID S p„ E c*PLAINTEXT EC *CRYPTO EC )*DS EC .Pnvate.Key 


i r < ^~~~-H3ither TID SP _ M 


r J~436 


REJECT or TrD SP-EC is invalid 


434 i 


SP uses PK M (see 150 and 170) to verify the decrypt DS^p^^^ (Refer to FIG. 5). 

D M-Public-Key( DS M-Private-Key ) =MD M> Is MD M =MD A M ? 



440 



NO 





1 


r YES f 442 


SP uses Skey M (see 210) to decrypt CRYPTO M ,and obtains Acknowledgment Data M 




r 444 


(1) SP separates DS EC .private-Key> (2) hashes the data portion of EC's acknowledgement 

message: H(TID SP _ EC *PLAIN TEXT EC *CRYPTO EC )=MD A EC 
(3) SP separates and obtains: TID SP . EC , PLAIN TEXT EC , CRYPTOgc, DS EC -Private-Key 




r 446 


SP uses PK EC (see 126 and 176) to decrypt DS EC . Private . Key (Refer to FIG. 5). 

DEC-Public-Key(DS E c.p rivat e-key) = MD EC , Is MD EC =MD A EC ? 


r 45 


0 

NO 3 


I 448 



REJECT 



MD* EC =MD EC ? 



1 


r YES 


r452 


SP uses Skey EC (see 186) to decrypt CRYPTO EC , and obtains Acknowledgment Data EC 


END OF TRANSACTION PHASE 


y 454 






TRANSACTION COMPLETED 
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FIG. 13 



60 



SERVICE PROVIDER(SP) 



i 
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DECLARATION AND POWER OF ATTORNEY 
FOR PATENT APPLICATIONS 



PATENT 



Docket No. : 34581/AH/C718 



As a below named inventor, I hereby declare that: 

My residence, post office address and citizenship are as stated below next to my name. 

I believe I am the original, first and sole inventor (if only one name is listed below) or an original, first and joint 
inventor (if plural names are listed below) of the subject matter which is claimed and for which a patent is sought 
on the invention entitled A CRYPTOGRAPHIC SYSTEM AND METHOD FOR ELECTRONIC TRANSACTIONS, 
the specification of which is attached hereto unless the following is checked: 

was filed on as United States Application Number or PCT International Application Number and was 

amended on (if applicable). 

I hereby state that I have reviewed and understand the contents of the above-identified specification, including 
the claims, as amended by any amendment referred to above. 

1 acknowledge the duty to disclose information which is material to patentability as defined in 37 CFR § 1.56. 

I hereby claim foreign priority benefits under 35 U.S.C. § 119(a)-(d) or § 365(b) of the foreign application(s) for 
patent or inventor's certificate, or § 365(a) of any PCT International application which designated at least one 
country other than the United States, listed below and have also identified below, any foreign application for 
patent or inventor's certificate, or PCT International application having a filing date before that of the application 
on which priority is claimed. 

Prior Foreign Application(s) 

Application Number Country Filing Date (dav/month/vear) Priority Claimed 

PCT/US99/09938 05/05/99 YES 

I hereby claim the benefit under 35 U.S.C. § 119(e) of any United States provisional application(s) listed below. 

Application Number Filing Date 

60/084,257 05/05/98 

I hereby claim the benefit under 35 U.S.C. § 120 of any United States application(s), or any PCT International 
application designating the United States, listed below and, insofar as the subject matter of each of the claims 
of this application is not disclosed in the prior United States or PCT International application in the manner 
provided by the first paragraph of 35 U.S.C. § 112, I acknowledge the duty to disclose information which is 
material to patentability as defined in 37 CFR § 1.56 which became available between the filing date of the prior 
application and the national or PCT International filing date of this application: 

Application Number Filing Date Patented/Pending/Abandoned 



POWER OF ATTORNEY: I hereby appoint the following attorneys and agents of the law firm CHRISTIE, 
PARKER & HALE, LLP to prosecute this application and any international application under the Patent 
Cooperation Treaty based on it and to transact all business in the U.S. Patent and Trademark Office connected 
with either of them in accordance with instructions from the assignee of the entire interest in this application; 



DECLARATION AND POWER OF ATTORNEY 
FOR PATENT APPLICATIONS 
Docket No. 34581/AH/C718 



or from the first or sole inventor named below in the event the application is not assigned; or from _ in the event 
the power granted herein is for an application filed on behalf of a foreign attorney or agent. 



R. W. Johnston (17,968) 

D. Bruce Prout (20,958) 

Hayden A. Carney (22,653) 

Richard J. Ward, Jr. (24, 187) 

Russell R. Palmer, Jr. (22,994) 

LeRoy T. Rahn (20,356) 

Richard D.Seibel (22,134) 

Walter G. Maxwell (25,355) 

William P. Christie (29,371) 

DavidA.Dillard (30,831) 

Thomas J. Daly (32,213) 

Vincent G. Gioia (19,959) 

Edward R. Schwartz (31,135) 



John D. Carpenter (34, 133) 

David A. Plumley (37,208) 

Wesley W. Monroe (39,778) 

John W. Eldredge (37,613) 

Gregory S. Lampert (35,581) 

Grant T. Langton (39,739) 
Constantine Marantidis (39,759) 

Daniel R. Kimbell (34,849) 

Craig A. Gelfound (41,032) 

SyedA.Hasan (41,057) 

Kathleen M. Olster (42,052) 

Daniel M. Cavanagh (41,661) 

Molly A. Holman (40,022) 



Lucinda G. Auciello (42,270) 

Norman E. Carte (30,455) 

JoelA.Kauth (41,886) 

Patrick Y. Ikehara (42,681) 

Mark Garscia (31,953) 

Gary J. Nelson (44,257) 

Raymond R. Tabandeh (43,945) 

Phuong-Quan Hoang (41,839) 

Jun-Young E. Jeon (43,693) 

KathyMojibi (41,409) 

Cynthia A. Bonner (44,548) 

Marc A. Karish (44,816) 



The authority under this Power of Attorney of each person named above shall automatically terminate and be 
revoked upon such person ceasing to be a member or associate of or of counsel to that law firm. 

DIRECT TELEPHONE CALLS TO : Craig A. Gelfound, 626/795-9900 

SEND CORRESPONDENCE TO : CHRISTIE, PARKER & HALE, LLP 

P.O. Box 7068, Pasadena, CA 91109-7068 

I declare that all statements made herein of my own knowledge are true and that all statements made on 
information and belief are believed to be true; and further that these statements were made with the knowledge 
that willful false statements and the like so made are punishable by fine or imprisonment, or both, under Section 
1001 of Title 18 of the United States Code and that such willful false statements may jeopardize the validity of 
the application or any patent issued thereon. 



Full name of sole or first joint inventor 

Jav C. Chen 


Inventor's signature 


Date 


Residence and Post Office Address 
1355 Blackstone Road, San Marino, California 91108 


Citizenship 
United States 
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